LPC546XX: SWD Locked?

[giusloq]

I have a custom board with LPC546XX that was working well with a J-Link debug probe over SWD.

Now it doesn't work anymore, JLink says it wasn't able to connect to the device.

I tried to power up the device with ISP0 connected to GND and it enters correctly into ISP mode over UART. Indeed I can sends commands over UART and the device replies correctly.

Even if I let the my application run (leaving ISP0 floating at startup), the MCU seems working well, but JLink isn't able to connect.

Any ideas?

[giusloq]

It's incredible! Yesterday exactly the same issue on a completely different PCB with a different MCU: LPC54101J512!!

I investigated again and I found that signal SWDIO is not normal. I expected this signal goes from 0V to Vcc during programming/debugging, but this is not the case on problematic MCUs. The range is limited, for example between 1V and 2V, measured by a scope.

So one reasoning for this is that the SWD pin/signal is broken inside the MCU. Why this happens so frequently recently on my boards? Could be my J-Link probe that is causing these issues?

Are LPC54 MCUs much more sensitive to ESD respect old LPC17? Because I used LPC17 and J-Link for many years now without any problem.

[Alice_Yang]

Hello,

Through your description, I think this is a complex hardware issue, recommend you create a submit a private ticket with your schematic:

https://support.nxp.com/s/  

BR

Alice

[Alice_Yang]

Hello,

Also you can try to use the  script "LPC546xxMassErase" to erase and read ECRP level, it can confirm whether the ECPR is configured by OTP.

https://community.nxp.com/t5/LPC-Microcontrollers/LPC5460x-ECRP-Lockout/m-p/1351480/page/2  

Only need check the one reply:

It describe detail steps.

About the meaning of CRP level return value:

Regarding this question, there is a table translation from the ECRP level user defined and the ECRP definition used by the ROM code:

/* Feature bit defines */

#define CRP_JTAG_EN_BIT         (1 << 6)

#define CRP_MASS_ERASE_DIS_BIT  (1 << 7)

#define CRP_IAP_PROT_EN_BIT     (1 <<8)

#define CRP_ISP_PINS_EN_BIT     (1 << 9)

#define CRP_ISP_IAP_EN_BIT      (1 << 10)

#define CRP_DBG_MBOX_EN_BIT     (1 << 11)

#define CRP_COUNT_MASK          0x3F

#define CRP_DEFAULT_FEATURES    0xFFFFFFFF

#define CRP_MASS_ERASE_ONLY     (CRP_SECT_ERASE_DIS_BIT)

For example:

In CRP_JTAG_EN_BIT, 1 is JTAG/SWD enabled and 0 is disabled. It’s corresponding to ECRP value bit 17 and 16.

In CRP_MASS_ERASE_DIS_BIT, 0 is Mass Erase allowed and 1 is disallowed. It’s corresponding to the combination of ECRP value bit 0~5, bit 10~11, and bit 14~15.

In CRP_IAP_PROT_EN_BIT, 1 is IAP protection enabled and 0 is disabled. It’s corresponding to ECRP value bit 14~15.

In CRP_ISP_PINS_EN_BIT, 1 is ISP pin enabled and 0 is disabled. It’s corresponding to ECRP value bit 12~13.

In CRP_ISP_IAP_EN_BIT, 1 is ISP in IAP mode enabled and 0 is disabled. It’s corresponding to ECRP value bit 14~15.

In CRP_DBG_MBOX_EN_BIT, 1 is ISP-AP or debugger mailbox enabled and 0 is disabled. It’s corresponding the combination of some reserved ECRP bits and OTP setting.

Of course, all these ECRP value used by the ROM not only look into the user defined ECRP value but also check the OTP setting.

When “Query ECRP Level” is called, it returns the value used by the ROM code, but not the ECRP value programmed in the image by the user.

Unfortunately, this table is provided in the User Manual.

BR

Alice

[giusloq]

Dear Alice,

I have two boards (identical PCB and same components mounted), one with LPC54618J512 fully functional and the other that appears to have SWD locked.

I tried to execute the script LPC546xxMassErase.scp on both of them with different results. I used LPCXpresso54628 EVB as debug probe.

As I understand, the problem is still there.

[Alice_Yang]

Hello ,

How many chips have the issue?

Please take a photo about your chip, show masking of chip, and I will ask whether there is suggestion from our internal.

And want to confirm with you again, 1) for first time, no download image into chip , does SWD can work well?   2) Then just program a simple hello world image, does SWD can work well? 

BR

Alice

[giusloq]

How many chips have the issue?

At the moment I have two boards with LPC54618J512BD208. One MCU doesn't allow SWD access (and only SWD access, others functionalities seems ok), the other MCU allows SWD access.

Moreover I have another board, this time only one board, with LPC54606J512BD100. This MCU now doesn't allow SWD acces.

Please take a photo about your chip, show masking of chip, and I will ask whether there is suggestion from our internal.

Se pictures attached. I'm sorry for the poor quality, I hope you can see the info you want. SWD_ok_MORFEO.png is the MCU that works well.

SWD_locked_APOLLO.png and SWD_locked_MORFEO.png are the MCUs that have SWD locked.

And want to confirm with you again, 1) for first time, no download image into chip , does SWD can work well?   

I have downloaded many images to the MCU without any problem. After some time, I don't know why, the debug probe wasn't able to connect to the MCU via SWD anymore.

I observed this exact behaviour on LPC546218 and LPC54606.

2) Then just program a simple hello world image, does SWD can work well? 

No, SWD access doesn't work for whatever image. As I wrote, the error is emitted well before downloading something. The debug probe isn't able to detect Cortex core so it stops immediately.

[giusloq]

Also you can try to use the  script "LPC546xxMassErase" to erase and read ECRP level, it can confirm whether the ECPR is configured by OTP.

Ok, I will give it a try, however I don't understand.

In the thread you cited, the user was playing with ECRP, disabling everything (IAP access, ISP pins, SWD access and so on).

In my case, I can enter ISP and I can mass erase through ISP commands. After mass erase, blank check is verified correctly, so ECRP value shouldn't be the cause of my problem.

The other possibility is OTP, but I never tried to write OTP memory and I download (via ISP) a firmware that reads and sent via UART the OTP content. I already reported these tests in one of my reply in this thread (see https://community.nxp.com/t5/LPC-Microcontrollers/LPC546XX-SWD-Locked/m-p/1466359/highlight/true#M48...).

[Alice_Yang]

Hello,

This script also can read the ECRP level. And yes I know you doesn't program OTP, just want to exclude this possibility. 

[Alice_Yang]

Hello ,

"I downloaded FlashMagic and I can write new firmware through UART entering ROM Bootloader by ISP pins."

->> It can download new image from ISP, so it must can erase all.  Try to erase , then debug again. 

There is a thread about "Regaining debug access to target MCU "

https://community.nxp.com/t5/LPCXpresso-IDE-FAQs/Regaining-debug-access-to-target-MCU/m-p/473923  

BR

Alice

[giusloq]

There is a thread about "Regaining debug access to target MCU "

https://community.nxp.com/t5/LPCXpresso-IDE-FAQs/Regaining-debug-access-to-target-MCU/m-p/473923  

I followed exactly what that post suggests. I can enter ISP UART mode without any problem, but the debugger can't see the MCU on SWD bus.

Moreover i couldn't find any "Vector catch" option in the debug launch configuration.

[Alice_Yang]

Hello,

After the above analysis, I think the issue should be hardware, how about try do not add external pull-up resistor, because this is internal pull-up:

You also can try to connect the SWD pins to LPCxpresso54628 EVK board, then connect debugger with EVK board, to debug your own chip to test.

BR

Alice

[giusloq]

After the above analysis, I think the issue should be hardware

It is possible, but at first both prototypes worked for some days.

how about try do not add external pull-up resistor, because this is internal pull-up:

I don't think mounting an external pull-up is problematic if there's an internal pull-up, anyway I just tried to unmount external pull-ups on SWCLK, SWIO e SWO. Same behaviour, J-Link couldn't connect to MCU.

You also can try to connect the SWD pins to LPCxpresso54628 EVK board, then connect debugger with EVK board, to debug your own chip to test.

Do you mean using the embedded debugger in EVK to debug an external MCU? Yes, I already tried. I moved JP2 to ext position and mounted JP1. I put a pin to pin cable between P1 of EVK and SWD header port of my custom board.

Nothing, same problem.

[Alice_Yang]

Hello,

"You also can try to connect the SWD pins to LPCxpresso54628 EVK board, then connect debugger with EVK board, to debug your own chip to test."

Do you mean using the embedded debugger in EVK to debug an external MCU? Yes, I already tried. I moved JP2 to ext position and mounted JP1. I put a pin to pin cable between P1 of EVK and SWD header port of my custom board.

->> NO, I meaning replace the LPC54628 SWD pins with your own chip lpc54606, want to use all the hardware of lpcxpresso54628-EVK. while it seems hardly. For example connect SWDIO to EVK board. 

Because as you described, chip can update firmware with ISP mode, and image can works well. Also have not program OTP. So, the most likely cause is the SWD hardware. And BTW, do you config the SWD pins to other functions in your application code?  

BR

Alice

[giusloq]

Try to erase , then debug again. 

Yes, I already tried. FlashMagic is able to erase, write and read internal MCU Flash memory without problems. After erasing all sectors (and checking with Blank Check option), I tried to connect by J-Link without success. Even after a power cycle.

[Alice_Yang]

Hello giusloq,

How about erase all after enter isp mode, than try again?

Or change to another debugger to have a try? 

BR

Alice

[giusloq]

How about erase all after enter isp mode, than try again?

I just tried and this is the result:

Synchronized
Synchronized
OK
U 23130
OK
P 0 15
0
E 0 15
15

It seems the MCU answers with error 15 to erase sectors command. It should be ERR_ISP_CMD_LOCKED.

What does it mean? Is it related to CRP or ECRP or OTP? I never used any of those features.

Indeed, word at 0x24 address is 0x000000 (Legacy Image):

R 36 4
0
00 00 00 00   <- in binary

I don't know if it is possible to read OTP memory by ISP.

Or change to another debugger to have a try? 

I tried the contrary. With the same debugger I tried to connect to a LPCXpresso54628 EVB and it works.

Now I'm mounting a second prototype of custom board and it works on this.

So the question is: what happened to the MCU of the first board and how to avoid the same behaviour on the second bootloader?

It seems all works perfectly, except SWD lines, even when entering NXP ROM bootloader.

[Alice_Yang]

Hello,

The offset address of ECRP is0x20:

From the returned value of ERASE command, I think you configure the ECRP or OTP .About ECRP, config it in image at offset 0x20. OTP, there is OTP API, detail you can refer to "Chapter 46: LPC546xx One-Time Programmable (OTP)".

BR

Alice

[giusloq]

The offset address of ECRP is 0x20:

Even ECRP word at address 0x20 is 0:

R 32 4
0
00 00 00 00   <- binary

I never wrote to OTP memory (at least intentionally), so if I understood well, CRP_ALLOW_ZERO bit is 0, so ECRP=0 is interpreted as:

All protections enabled by ECRP field will be set to lowest protection level. So, flash ECRP value is interpreted as SWD, ISP entry, IAP entry, write and erase of all flash sectors are allowed.

So SWD should be enabled.

I don't think I wrote OTP memory unintentionally, because I should had used OTP API, so I should had called otpInit() and other similar functions. There isn't any of this in my code.

Is there any way to read OTP memory with UART ISP?

[Alice_Yang]

Hello,

Try to read the address 0x4001 5030. 

[giusloq]

Try to read the address 0x4001 5030. 

Here it is

R 1073827888 4
14

The error 14 should be ERR_ISP_ADDR_NOT_MAPPED:

Address is not mapped in the memory map. Count value is taken into
consideration where applicable.

It seems it isn't possible to read OTP memory from ISP UART commands.

Anyway, how OTP could be written if I never used OTP API in my code? Is there another way to write OPT memory?