AnsweredAssumed Answered

LPC2138/2148 CPU Flash read problem

Question asked by Sutton Mehaffey on Sep 24, 2019
Latest reply on Sep 27, 2019 by Alexis Andalon

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

Outcomes