I'm working on two different prototypes of two different boards with two different MCUs of the same family: LPC54618 and LPC54628 by NXP.

Initially J-Link is able to make a good connection via SWD and I can download new firmware, debug and so on.

However, it happened two times (the first with one board and the second on another board) that J-Link wasn't able to connect to the MCU anymore. In the first case, I mount a completely new PCB (with a new MCU) and now it is working well, but the original MCU seems bricked.
In the second case, I decided to replace the MCU on the board, but the error is still there: J-Link can't connect via SWD.

After some tests, I understood that the MCU is fully functional: the application that resides in the Flash runs without any problem. I'm also able to enter ROM UART Bootloader via ISP pins and I'm able to download a new firmware via UART.

It seems only SWD port/pins is locked, but I don't know why.

I investigated ECRP (a method from NXP that enables some restrictions on the MCU, i.e. SWD access), but it seems all is allowed and unlocked.

I already asked NXP guys, but without success at the moment. I write here, maybe it's something related to J-Link and not NXP.

Fabian wrote:

Usually such a Problem is connected to one of the three following points.
The application
1) re-configures the debug pins as GPIOs.

I think this is not my case for a simple reason. I can enter ROM Bootloader by keeping low one ISP bootstrap pin. When in Bootloader, my application doesn't run at all. However, even when the ROM Bootloader is active, SWD doesn't work (while on EVB I can connect through SWD during Bootloader).

Fabian wrote:

2) enables chip security (by accident or on purpose)

At the beginning I was thinking of this. LPC546XX has a method, called ECRP, that could lock SWD access by a magic work in Flash or writing some bits in OTP memory. However I can erase entire Flash (through UART ROM Bootloader) and the bits in OTP memory seems at their default values (identical to EVB).

Fabian wrote:

3) makes use of low-power modes that disable all debug related clocks inside the chip.

Not in my case, when I enter ROM Bootloader.

Fabian wrote:

If you are sure that the replaced MCU is soldered correctly on the PCB, I would advice to check if the signals between MCU and debug header are actually connected through.
Maybe the lanes on the PCB were damaged or some peripheral is active that influences the signal integrity of the debug lanes.

Yes, MCU is soldered correctly because I can see SWDIO and SWCLK pins toggling (directly on the debug header connector) when the application re-configures them as GPIO.

I don't know what to think.

Hello Fabian,

I know it's incredible, but three times I experienced this problem on three differrent PCBs and MCUs: LPC54101, LPC54618 and LPC54606. J-Link returns the error "Could not connect to target", it seems SWD access is locked on the MCU.

I don't know what's the problem is, but I'm starting thinking of the J-Link that could be malfunctioning (even if it works great with other boards and MCUs).

I have the latest J-Link software and I tried to restart from a blank project, without any success.

In all three cases, I am able to enter USART ISP Boot and erase internal Flash memory, but SWD access again is impossible even after chip erase.

Could be the J-LINK malfunctioning and destroy SWD of connected MCUs?

After some investigations, I found something interesting on SWDIO pin. When the probe is able to connect to the MCU, SWDIO signal goes high and low without problems: I can see 0V and Vcc on scope.
On MCUs that are broken, SWDIO swings in a more restricted voltage range: for example from 1V to 2V.

It seems SWDIO is broken inside MCU, but this happend THREE times! Is it possible that J-Link is responsible for this? Is it possible that a malfunctioning J-Link could apply a somewhat high voltage on SWD lines during programming?

I'm thinking that J-Link could be the cause of all these issues because they happened recently three times with three different MCUs and three different custom boards. I used this J-Link probe for many years without any problems on many MCUs, but recently I have all these issues.

Ok, but this happened on three different boards. If there's a problem on my hw, it is repetitive on multiple boards and MCUs.
This isn't the first board we design, we don't explain what is happening.

Until now no, I have these issues only on custom boards. Anyway they are very similar to EVB, at least for SWD lines connection.
Only LPC546xx EVB has protection diodes on SWD lines, while I don't have them on my custom board.


It's 3.3V as normal.

On boards that mount good MCUs, SWD lines swing normally between GND and VDD. As I wrote, if I connect broken MCUs, SWDIO line isn't able to go to GND and to VDD. Look at the picture attached. The upper trace is VDD, while the lower trace is SWDIO. The reference for both channels are at the same point. It's evident there's some problem with SWDIO.he problem is inside MCU.

I suspect something has broken inside the MCU on SWD lines, but only J-Link is attached to these lines.

50116485

However we are testing ground connections. We measured around 20Vac between board ground and J-Link ground, before connecting them.

I'm suspecting that the problem can arise when I hot-plug J-Link flat cable to the board.

The board is supplied from an AC/DC with its metallic case connected to earth and the reference of its output +12Vdc is connected to earth too. The PC is a standard desktop computer connected to a UPS.
I don't know why there's such a residual alternate voltage, most probably caused by mains 230Vac.

I make a good connection between metallic case of my desktop PC and metallic case of AC/DC that powers the board and now I don't see 20Vac residual voltage anymore. Maybe this could be the cause of my issues.

What do you suggest to have a good workbench in this scenario?