LPC5460x ECRP Lockout

[corytodd]

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?

[Alice_Yang]

Hello corytodd,

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.

1. Please place LPC546xxMassErase.scp to C:\nxp\MCUXpressoIDE_11.4.0_6237\ide\binaries\Scripts.
2. Open a Command Prompt window.
3. Change the path to C:\nxp\MCUXpressoIDE_11.4.0_6237\ide\binaries.
4. Execute the command of redlinkserv -commandline.
5. After the execution of the command of redlinkserv -commandline, you should see redlink> prompt.
6. Execute the command of load "C:\nxp\MCUXpressoIDE_11.4.0_6237\ide\binaries\Scripts\LPC546xxMassErase.scp".
7. After the execution of the command of load "C:\nxp\MCUXpressoIDE_11.4.0_6237\ide\binaries\Scripts\LPC546xxMassErase.scp", you should see Loading " LPC546xxMassErase.scp".
8. Execute the command of run.
9. After the execution of the command of run, you should see messages below.

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.

1. Open a Command Prompt window.
2. Change the path to C:\Program Files (x86)\SEGGER\JLink.
3. Execute the command like shown below:
• JLink.exe -Device LPC54605J512 -If SWD -speed 4000 -CommanderScript "The path of LPC546xxMassErase.jlink "

[corytodd]

Hi Alice,

We'll have to order an LPC Link since we only have J-Links in-house for debugging. Please give us about a week to test this.

[Alice_Yang]

Hello corytodd,

How about this issue now? You can also try to use the lpc-link on EVK board, for example lpcxpresso54628 board if you have.

BR

Alice

[corytodd]

Hi Alice,

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.

[Alice_Yang]

Hello ,

Ok, waiting your feedback.

BR

Alice

[Alice_Yang]

Hello corytodd,

If the devices with this issue are all 256KB device?

Please answer, I have escalate your case into SE team, they ask this question.

BR

Alice

[corytodd]

Hi Alice,

My apologies for the delayed response, our team has been out on holiday.

We have experience this issue with both the 256KB and 512KB parts.

[Alice_Yang]

Hello corytodd,

Could you please help to get the boot code version between good and bad device?

Thanks.

BR

Alice

[corytodd]

The boot code on a good board is 0xcccc0003.

We are unable to read the boot code from the bad board since we cannot update the firmware on it.

[Alice_Yang]

Hello corytodd，

If the devices with this issue are all 256KB device?，

BR

Alice

[guitardenver]

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?

[Alice_Yang]

Hello ,

What about the version of the chips?

Please take a photo about the mask of them.

BR

Alice

[guitardenver]

Alice,

Here are two images. Each MCU has the issue.

[Alice_Yang]

Hello guitardenver,

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.

BR

Alice

[corytodd]

Hi Alice,

All parts are from official distributors, from a wide range of datecodes/lots.

Here is a picture of one that is working.

On working chip, jlink unlock works say "successful, power cycle the mcu"

On a locked out chip, jlink unlock says "unlock failed".

[guitardenver]

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.

[BrunoSenzio]

Hello,

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,

[guitardenver]

Bruno, we are not trying to recover the code inside the MCU. We are trying to recover SWD access. SWD is the thing that is disabled.

[BrunoSenzio]

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.

Best Regards,

Bruno

[corytodd]

Hi Bruno,

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.

Thanks!