We are using an LPC5460x part with ECRP and a legacy boot image. We are finding that some of our parts, after setting the ECRP bits for release, can no longer be unlocked or mass erased. The parts are stuck with whatever firmware they had loaded on them and we can never update them. One or two parts are completely disabled, most like due to the section 2 of chapter 3.3.1 of the UM10912 manual.
What we don't understand is that most of the time things work just fine, we can flash a release image over a debug image, then revert to a debug image as needed.
The ECRP we are using:
bits set (0x00015800)
11 - IAP Sector Erase/Write protection is disabled.
12 - Do not allow ISP entry via pins
14 - Do not allow ISP entry via IAP call
16 - Disable external access to chip
No OTP registers are written by our code. Any suggestions on what we could be doing wrong here?
I just got new reply from SE team as below, you can refer to the method to unlock your chip.
We are confirming with Segger, they still doesn't clarify what the J-Link unlock command would do. So we are still following up this issue.
We provide another way, customer can test it. Please see attached zip, it has two scripts, suggest they use LPC546xxMassErase.scp with EVK on-board LPC-Link and MCUXpresso IDE first.
Assume that MCUXpressoIDE_11.4.0_6237 is installed in C:\nxp\MCUXpressoIDE_11.4.0_6237.
If customer doesn’t program any OTP field, then it should work.
I also provide a J-Link command script, just for reference, still suggest they use above method first, to avoid the impact of JLink tool set.
Assume JLink is installed in C:\Program Files (x86)\SEGGER\JLink.
We have received the boards and are working on getting it connected to our hardware. Our board isn't laid out to support a Link2 so it will take us some time to get everything working.
We did confirm that the Link2 with your provided erase script works with an OM13092 dev board. However, we have not been able to get the Link2 connected to our part so we'll get back to you.
Our vendor got the PCBs back to us. We sent them a working board and a broken one. They put the working boards MCU on the broken board and the broken boards MCU on the good board.
The problem followed the MCU as expected. The good board is now broken and can't be programmed and the bad board can be programmed now.
What would be the next step to sending this into NXP for analysis?
Thanks for your sharing.
I checked errata and other cases, have find information about this.
Do the products come from official distributor?
Please also take pictures about the chips that work well.
Also show the information when unlock with J-link.
The issue is not updating the firmware. The issue is that SWD access is being completely disabled and stuck disabled when it should not be.
But only on SOME units. The same firmware image was loaded on about 40 different MCUs and only about 8 were NOT recoverable.
Using the SEGGER JLink and their tools we can unlock and recover SWD access just fine. We confirmed the flash contents were secure because you could not read the contents out. But on a few units, recovery was not possible. We tried via JLINK and P&E debugger hardware.
So this means, the ECRP bits we set, is not completely disabling SWD to a point it can't be recovered/mass erased via SWD because all units would be unrecoverable.
Is there some other way for recovery? Any idea why some units are acting differently? Note that non of our code is writing any OTP bits.
We tried using the IAP command EraseSector to do a "Mass Erase" as describe below:
But this did not recover SWD access either. Which means our bootloader is now erased and the MCU is completely bricked.
My two cents on this one is to implement some sort of "secure code retriever firmware" to perform secure handshake and allow to retrieve the code besides the options that have already been implemented.
Does that sound like a crazy idea?
Thanks and regards,
Hello guitardenver and Cory,
I am not sure if this has been resolved so far. If this has not been solved, could it be possible to ask you with the following?
1. Replace a bad(locked) part with a good (working part) board (a board that has already gone through the SWD disable, then chip erase, and reprogram)
2. Could you check the lot dates of these parts? (just to see if this could be part of the issue)
3. What Field Analysis ruled have you followed so far? Would be important to continue following a couple more until the root cause is found?
Thank you for your time in advance.
We're working on step 1 today and will let your team know the results.
The lot codes are from different batches so we don't think this is lot specific.