From: Claudio Lapilli on
Hi,

On Feb 19, 8:21 am, "tiwag" <tiwag...(a)gmail.com> wrote:

> but now running an arm-program with PrRUN freezes my calc,
> no difference if using ARMToolBox 3.10 or 3.12 (with gcc 4.0.2 or
> 4.1.1)

Some people have reported before freezes like the one you describe. It
seems to respond to a particular flash memory configuration (of
installed libs+deleted libs,not which libs you have, but their
particular layout in memory), that I could never reproduce (here it
worked every time). Most people solved it by reinstalling the
ARMToolbox, try several times if necessary.


>
> can the installation of one of the following libraries
> affect the proper operation of the ARMToolBox PrRun command ?
>
> L1789 SDiag 2.11
> L1790 Emacs 2.11a
> L1625 Nosy 4.1
> L258 extable
> L360 OT49+
> L1200 Keyman+ 5.2004

No, I use all those libs + some others and everything works OK.


Claudio

From: tiwag on
On 20 Feb., 00:55, "Claudio Lapilli" <pleasedonts...(a)isp.com> wrote:
> Some people have reported before freezes like the one you describe. It
> seems to respond to a particular flash memory configuration ...

i removed all libraries from port 2 and installed the ArmToolbox
again, and it didn't work, what else can it try?


what is the difference in execution between running the arm-program
string with PrRUN versus executing S->EXE first on the the arm-program
string and evaluating that ?
with PrRun my calc freezes, with S->EXE and EVAL it runs fine -
weird !

thx,
--tiwag











From: mm on
tiwag schrieb:
> On 20 Feb., 00:55, "Claudio Lapilli" <pleasedonts...(a)isp.com> wrote:

<..>
> what is the difference in execution between running the arm-program
> string with PrRUN versus executing S->EXE first on the the arm-program
> string and evaluating that ?
> with PrRun my calc freezes, with S->EXE and EVAL it runs fine -
> weird !

The difference is, that with S->EXE a complete ARM code launcher is
being linked to the program, thus forming a standalone exe.
With PrRUN in contrast, the launcher is invoked in the library.
So I guess my assumption about mis-alligned code inside the lib in flash
could be true.
You should procure a tool, with which you can inspect the physical
layout of your flash. I believe Thomas Rast once wrote something
appropriate and it's available at hpcalc.org.

--
Ingo Blank

http://hpgcc.org
http://blog.hpgcc.org

From: John H Meyers on
On Tue, 20 Feb 2007 11:48:01 -0600:

> You should procure a tool, with which you can inspect the physical
> layout of your flash. I believe Thomas Rast once wrote something
> appropriate and it's available at hpcalc.org

http://www.hpcalc.org/search.php?query=pfree

Written for 49G, it displays a little bit of garbage
for unavailable banks in ARM-based calcs, but doesn't crash.

Reading the documentation is somewhat necessary
to understand what it can or can't do
(are you sure it can identify the exact
address alignment that's needed by the toolkit?)

[r->] [OFF]
From: tiwag on
@JHM thanks for the tip with pfree !


With the usage of pfree i could solve the puzzle.

1. examined the flash banks and found a lot of deleted ARMToolBox
libraries (versions 3.10 and 3.12) from my previous install tries in
flash banks 8, B and C.

2. purged the last active ARMToolBox library and continued with
installing of some libraries until bank B was nearly full

3. finally installed the ARMToolbox again, pfree told me that it is
located as first object in bank A

now my ARMToolBox PrRun command works fine again.


seems to be a problem with the installation of the ARMToolbox (ATB),
which arised when i wanted update ATB from version 3.10 to 3.12

obviously i purged ATB 3.10 and installed ATB 3.12 which didn't work
until it got stored as first object in an other flash bank.

@Claudio - can you develop a small tool which tests/detects the im/
proper alignment of the ATB ! after installation ! to the flash
port ?

thx
--tiwag