IAP Gotcha( Don't do this) and Internal Flash question

Started by lhaddix May 19, 2006
Hi,
I'm working with an LPC2138 and spent the day getting IAP
and interrupts all working at the same time.

In the course of this I think I scanned every IAP post on the
list. Lots of folks reported erratic behavior afterward.

I too had 'erratic behavior', the cause was the IAP API using
the top 32 bytes of RAM. Nothing up there anyhow right?

Well my stack was up there and it's much better now that stack
top is at 0x40007FE0. Also you need to go into the .ld file and
say the size of RAM is 0x7fe0 not 0x8000.

I'll bet this same problem has harpooned more than one programmer.

My remaining problem...

Now what I'm up against is that to do a read sector into ram/ modify/
write back to flash sequence needs a full 32k for the large sectors.

It looks like just as with many flash device you can only set bits
to zero, not restore ones. It takes a sector erase to get them back
to ones which kills all of the data in the sector unless you can
buffer it and write it back. Anybody been here and worked around this?

Landrum





An Engineer's Guide to the LPC2100 Series

--- In l..., "lhaddix" wrote:
> Well my stack was up there and it's much better now that stack
> top is at 0x40007FE0. Also you need to go into the .ld file and
> say the size of RAM is 0x7fe0 not 0x8000.
>
> I'll bet this same problem has harpooned more than one programmer.

One client struggled with similar problem for weeks. The system state
for watchdog recovery was stashed in this area. Things worked fine
until IAP flash writes were called.

I think if you read the fine print in the user manuals you can work
out not to the 128 bytes at the top if you are using IAP, and 128
bytes at the bottom if you are using ISP.

> My remaining problem...
>
> Now what I'm up against is that to do a read sector into ram/ modify/
> write back to flash sequence needs a full 32k for the large sectors.

One client had a field update constraint that requires flash updates
to be done by reading, modifying, then updating in one go without any
external input betweeen the erase of the sector and its rewrite.

They had to drop off the LPCs for this reason alone.

One wonders what purpose the designers had in mind for two 64K sectors
in the middle of the flash address space, flanked by 8 x 8K sectors on
either side. This what they did for LPC2292.

Jaya

lhaddix wrote:

>Hi,
>
>It looks like just as with many flash device you can only set bits
>to zero, not restore ones. It takes a sector erase to get them back
>to ones which kills all of the data in the sector unless you can
>buffer it and write it back. Anybody been here and worked around this?
>
>
>
Yes, that is why I depend on an SD card instead of flash to store big stuff.

Regards,

TomW

--
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------