LPC5460x ECRP Lockout

cancel
Showing results for 
Search instead for 
Did you mean: 

LPC5460x ECRP Lockout

2,887 Views
corytodd
Contributor III

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?

Labels (1)
0 Kudos
40 Replies

670 Views
Alice_Yang
NXP TechSupport
NXP TechSupport

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.Alice_Yang_0-1642406061809.jpeg

     

  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".Alice_Yang_1-1642406062130.jpeg

     

  8. Execute the command of run.
  9. After the execution of the command of run, you should see messages below.Alice_Yang_2-1642406062126.jpeg

     

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 "
0 Kudos

624 Views
corytodd
Contributor III

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.

0 Kudos

578 Views
Alice_Yang
NXP TechSupport
NXP TechSupport

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

0 Kudos

566 Views
corytodd
Contributor III

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.

0 Kudos

540 Views
Alice_Yang
NXP TechSupport
NXP TechSupport

Hello ,

Ok, waiting your feedback.

 

BR

Alice

0 Kudos

937 Views
Alice_Yang
NXP TechSupport
NXP TechSupport

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

0 Kudos

855 Views
corytodd
Contributor III

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.

0 Kudos

831 Views
Alice_Yang
NXP TechSupport
NXP TechSupport

Hello corytodd,

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

Thanks.

 

BR

Alice

0 Kudos

822 Views
corytodd
Contributor III

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.

0 Kudos

966 Views
Alice_Yang
NXP TechSupport
NXP TechSupport

Hello corytodd,

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

 

BR

Alice

0 Kudos

1,112 Views
guitardenver
Contributor IV

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?

0 Kudos

1,100 Views
Alice_Yang
NXP TechSupport
NXP TechSupport

Hello ,

What about the version of the chips?

Please take a photo about the mask of them.

 

BR

Alice

0 Kudos

1,088 Views
guitardenver
Contributor IV

Alice,

 

Here are two images. Each MCU has the issue.

guitardenver_0-1639607411745.jpeg

guitardenver_1-1639607423316.jpeg

 

 

0 Kudos

1,055 Views
Alice_Yang
NXP TechSupport
NXP TechSupport

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

0 Kudos

1,033 Views
corytodd
Contributor III

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".

0 Kudos

1,916 Views
guitardenver
Contributor IV

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:

 
 

image (3).png

 

 But this did not recover SWD access either. Which means our bootloader is now erased and the MCU is completely bricked.

 




0 Kudos

1,859 Views
BrunoSenzio
Contributor III

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,

0 Kudos

1,851 Views
guitardenver
Contributor IV

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.

0 Kudos

1,494 Views
BrunoSenzio
Contributor III

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

0 Kudos

1,485 Views
corytodd
Contributor III

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!

0 Kudos