My customer is experiencing an issue with the LPC54018J2M.
The situation is described as follows:
After the customer updates the firmware by programming the new version into the Ether Back Up CODE block via I2C, upon reboot, the BOOT CODE first checks if there is a newer firmware in the Ether Back Up CODE. If there is, it overwrites the Ether CODE and then executes it.
flash memory arrangement
|-------------------------------------| 0x10000000 - 0x1000FFFF
| BOOT CODE(64k) 10000|
|-------------------------------------| 0x10010000 - 0x100fffff
| Ether CODE(960k) f0000|
|-------------------------------------| 0x10100000 - 0x101effff
| Ether Back Up CODE(960k) f0000|
|-------------------------------------| 0x101f0000 - 0x10200000
| reserved(64k) 10000|
|-------------------------------------|
For a small number of units, after the firmware update is completed, the software runs normally for a period of time. However, after some time, the code suddenly gets stuck. In these cases, even attempting to reprogram or erase cannot recover the system, and the IC has to be replaced.
For the abnormal ICs, we performed further tests using JTAG. Initially, program the sample code would not run normally, the IC would get stuck immediately after flashing.
For the customer software, the BOOT CODE checks the Flash Memory and then gets stuck during the SPIFI Initialization.
However, after programming the sample code from SDK_2.x_LPC54018J2M (version 24.12) via JTAG, the IC can operate normally, and subsequent programming also works as expected.
For abnormal ICs, directly reprogramming the customer code does not restore proper operation. It is necessary to first program the sample code in order to recover from the abnormal state.
The customer code is currently developed based on SDK 2.11.
The sample code that restores normal operation is from SDK 24.12.
I have also suggested that the customer update to the new version if possible, but this may require some time.
Therefore, I would like to discuss here what could be causing this issue—whether it is related to the SDK version, or if the memory configuration needs to be adjusted.
Although we can currently recover the device via JTAG, we hope to find a way to completely prevent this problem from occurring.
