Stefan wrote:
> Which µC and which Flash?
>
> I need code for µC AT91R40008 and Flash-ROM AT49BV322A in order to build
> a GPS datalogger.
>
> Perhaps we can work this out together?

I'm using AT91SAM7S64 and I mean internal on-chip flash not external.
Unfortunately I don't have any experiances with external flash.

Martin

Martin Gajdusek wrote:
> I place my Flash_write function into RAM but
> program frozen when I try to write anything into flash, but information
> is stored correctly! Under IAR EW I don't have problem. Thanks for any
> suggestion

"Program frozen" is not very informative. Has the processor generated an
exception, stuck polling an event that never occurs or what? You need to
determine what it is doing and how it got there.

Such events can occur for many reasons, and are no doubt down to the
code you are using. It is not uncommon for faulty code to appear to work
on won compiler and not another - if for example it is due to accessing
uninitialised data or out-of-bounds access, the results will depend on
what gets stomped on or the value of the invalid data - this is likley
to be different because of the compiler's different code generation and
code location.

Presumably if you call the Flash_write() function, and it does not
return, but the data is still written, then teh problem occurs late in
the code (after the actual write process). Possibly you are corrupting
the return stack with an out of bounds array access on a local variable,
or exceeding its maximum size and stomping on the static data or code
space. This will typically cause the code to 'return' to the wrong
address. If this address is not MMU mapped, a data abort will occur.
Even if it is MMU mapped, the 'code' at sich a location is unlikely to
make any sense and an abort would occur in any case.

If you have debug hardware, this should be easy to determine. If not,
then toggling some I/O in the exception handler and monitoring it with a
scope or an LED will at least tell you that the exception has occurred.

Clifford