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?

[BrunoSenzio]

Dear corytodd,

I would just like to add the suggestion I believe NXP made to me in this regard:

- Please check which batch has the problem

- For the other batches, the unlock method works normally for the chip, correct?

Thank you very much for your time and patience in advance.

Best Regards,

Bruno

[Alice_Yang]

Hello Bruno,

The chips can't recovery are come from same batches?

BR

Alice

[guitardenver]

All,

One of the units has a 2020 date code and another has a 2018. So it does not seem batch specific. 

We are working with our PCB vendor to put a bad MCU on a good board and a good MCU on the bad board. Once they are done, we will attempt to program both and see the results.

[BrunoSenzio]

Hello Alice,

It seems they belong to different batches.

Best,

Bruno

[Alice_Yang]

Hello Bruno,

 So I think they should check which batch has the problem, and in normal chip without any change, the unlock method works well. 

BR

Alice

[corytodd]

edit: posted as reply below

[Alice_Yang]

Hello corytodd,

So how do you want to update your firmware after your ECRP configuration?

BR

Alice

[corytodd]

Hello Alice,

We would like to be able to mass erase and reprogram via SWD but prevent others from reading out the contents of ROM.

[Alice_Yang]

While you have disable SWD

16 - Disable external access to chip

[corytodd]

Hi Alice,

Yes, I realize that sounds silly. However, that's the only way we found to prevent reading out the ROM contents per table 1022.ECRP of UM10912 regarding SWD ENABLE.

"Internal memory contents can be read or compared."

Also, SEGGER's JCommand can unlock the part with SWD access "disabled" so there is more to the ECRP than we are understanding. Can you suggest an alternative?

We want to disallow SWD from reading ROM/RAM but allow mass erase. This has been simple on every other part we use but this LPC part does not seem to offer such an option that we can find. More problematically, the behavior is inconsistent.

[Alice_Yang]

Hello corytodd,

OK, I know your meaning.

How about mass erase command?

And pay attention, the OTP MASS ERASE need enabled.

https://community.nxp.com/t5/LPC-Microcontrollers/Flash-Programming-access-block-in-LPC54608J512BD20...  

BR

Alice

[corytodd]

Hi Alice,

It sounds like you're saying it is impossible for us to make the ECRP meet our requirements. We aren't using the ISP module so that post doesn't quite pertain to us but I appreciate the information. We do have the CRP MASS ERASE DISABLE OTP bit clear which is the default state.

Are there any other solutions for this besides ISP?

[Alice_Yang]

Hello corytodd,

No, I mean it possible. while sorry  I haven't test on my side. There is customer successful unlock it.

Using J-link,  "unlock LPC5460x" command to unlock it.

You can have a look at this thread:  

https://community.nxp.com/t5/LPC-Microcontrollers/LPC546xx-MASS-ERASE-ulink2/m-p/1048588  

BR

Alice

[corytodd]

Hi Alice,

Yes, that's the method we use and it works about 80% of the time. That leaves us with 20% that we cannot unlock meaning the SWD appears to be permanently disabled.

Since some of these units have out bootloader on them we're able to load new application code. As a test we wrote a firmware that erases the ECRP vector to see if that would unlock the chip. Doing so does not restore SWD access. Additionally, we wrote a test firmware to issue a mass erase command which succeeded in wiping all the code but did not restore SWD access.

[BrunoSenzio]

Hi Cory,

In that same sense, if there is a problem on bringing the SWD access with all the other methods, what I was thinking is not to disable it at all but only provide access for SWD either by firmware with some sort of secure handshake or to put some condition by hardware not to enable SWD unless it is met. Would this be an option?

Regards,

[BrunoSenzio]

Hello,

I am not sure if I am on the same channel here, but, does the idea of a boot loader sound weird?

I was just going through this one but seems its for the LPC1100 and LPC1300 only...

https://www.nxp.com/docs/en/application-note/AN10968.pdf

Cheers

[corytodd]

Hi Bruno,

Not weird at all! We are using a bootloader, we just need a way to be able to update the bootloader once the chip is secured.

[BrunoSenzio]

Hi corytodd,

If such is the case, the only idea that came into my mind is encryption...

https://www.nxp.com/docs/en/application-note/AN4605.pdf

https://www.nxp.com/docs/en/nxp/application-notes/AN12352.pdf

The idea would be that the bootloader relies on private key cryptography wherein the key is stored in the bootloader and is known only in the development environment and the MCU. The aim is to keep the encryption key secret from all third parties to protect the firmware.

I am not sure for the LPC5460x though...

Would this help?

Thanks and regards,

[corytodd]

Hi Bruno,

Thanks for the input but we do have the encryption portion of our bootloader working as intended. Our question is about ECRP and how to get around SWD prohibition.

[BrunoSenzio]

Hi Cory,

Seems then that IAP might end up being the alternative here. The use of the "unlocker firmware" with encryption would be a great idea as mentioned.

Once again, thank you for your time and attention.

Best Regards,