LPC2138/2148 CPU Flash read problem

[sutton]

OK, I have a weird problem that I'm trying to solve with a LPC2138/2148.  I have an application that has my own custom bootloader at 0-4fff.  My application code starts at 5000.  The bootloader's sole job is to run a firmware update from an SD card, when prompted by the user.  So the upload code and the verify code is all located in the bootloader.  The procedure is that the user invokes the update from the application code, a 'firmware update' byte is set to indicate such, a watchdog timer occurs, and the update happens when the bootloader sees that the firmware update byte has changed.  The new update code goes directly from an SD card into the CPU flash starting at 0x5000 via IAP.  If the firmware update byte is not set, the bootloader just transfers to the application code.  The update firmware code is located on an SD card.  It works great for the most part.

Issue:

1.  The code uploaded from the JTAG and the SD card are the same.  If I upload code from the JTAG and run my 'Compare_SD_to_CPU_Flash' code, it verifies 100%.  About 225000 bytes starting at 0x5000.

2.  If I upload code from my 'Upload_SD_to_CPU_Flash', and verify by 'Compare_SD_to_CPU_Flash', it works about 5 times and then random bytes do not compare correction from SD to CPU Flash.  However, when I look at the address locations on the SD card and the CPU Flash via debug, the bytes are the same.

3.  If I reload code by #1, the Compare works 100% of the time again.  Until I reload via #2.  Then after 5 or so uploads from the SD card, it stops comparing correctly again almost every time.  It does verify all bytes occasionally.  Not sure what the issue is.

When I debugged what was going on in the Compare_SD_to_CPU_Flash code after the problem started, I found that the problem byte read from the CPU flash location was not actually the right value.  It was always off by 1 bit (usually bit 0, bit 5, or bit 8), and only one bit.  For example,

if the complaining address in the CPU had 0xA8, the byte read was 0xA9 and when matched with the 0xA8 on the SD card, it failed.  I found that sometimes if I read the CPU flash byte again, it would read 0xA8 and the compare would succeed.  The SD card data always reads correctly.  So not sure what is happening after uploading from the SD card about 5 times why the compare starts failing and will remain failing until reflashing with the same code from the JTAG.  Not sure why a CPU Flash read would ever give a bad read, unless there is a timing issue of some sort.  I did turn all interrupts off.  But that didn't solve the problem.  I have seen A8 read as A9, 00 read as 20, and 00 read as 80.  I think those are the only failures I've seen in the numerous times I have seen this problem.

Any ideas from anyone?

Thanks.

Sutton

[Alexis_A]

Dear Sutton,

Usually the flash operation should be located in other memory to not interfere with the code execution, your bootloader is copied to RAM or is executed from flash?

However, the LPC2138 is no longer recommended for new designs. So I wil suggest to check the LPC54xxx/LPC55xxx family.

Best Regards,

Alexis Andalon

[sutton]

Not sure what your comment means. This system is an older design. All

flash operations are in my bootloader and do not interfere with the

normal code.

Sutton Mehaffey

Lookout Portable Security

4105 Royal Dr. #100

Kennesaw, GA 30144

770-514-7999

770-514-1285 (FAX)

www.lookoutportablesecurity.com

sutton@lookoutportablesecurity.com

[Alexis_A]

Hi Sutton,

Could you let me know how are you writing to flash the code? Did you first store the code in the memory and after that update the code or update byte per byte?

Also Which IAP commands are you using to write the memory?

Best Regards,
Alexis Andalon

[sutton]

Alexis,

I am actually programming CPU RAM (starting at 0x40007000) with the code

and using IAP commands to program from RAM to Flash (command 51). We

have a firmware upgrade application that has worked for years. The way

it is done is to read a 1K block from a SD card, write it to RAM, then

upload from RAM to Flash. Continue with 1K blocks until the code is

written.

The issue I had is that after the code is in Flash, I noticed on a new

batch of chips that after programming the flash, the verify of whether

the SD card matches the code flash fails on occasion. But, then it

works for a while. Then, it doesn't. No code memory changes. Just

compares with the SD card. When it failed, I printed out the memory

location and bytes on the SD card and CPU Flash. The locations are

somewhat random.

I found when just reading the code memory, the locations don't always

read correctly. Most of the time they do.

I've changed the chips to a different batch and never had the issue

anymore. So, I think it is a bad batch.

Sutton

Sutton Mehaffey

Lookout Portable Security

4105 Royal Dr. #100

Kennesaw, GA 30144

770-514-7999

770-514-1285 (FAX)

www.lookoutportablesecurity.com

sutton@lookoutportablesecurity.com

[Alexis_A]

Hi Sutton,

Knowing this information, I also think this could be a quality error. Please contact your distributor.

Best Regards,

Alexis