I know it's a very specific question, so I don't have many hopes to find a solution here, but I already tried everything and I don't know how to solve the issue I have that is very annoying. I have three PCBs: PCB1 that mounts LPC54101 (M4), PCB2 that mounts LPC54606 (M4), PCB3 that mounts LPC54618 (M4). All these MCUs are from NXP. After I receive the first prototype for each board, I was able to make a connection through SWD, by using a J-Link probe. I use MCUXpresso as the IDE for debug launch. Well, after some tests (write some code, download new images, debug some and so on), I received an error from the probe: no SWD target found (Could not connect to the target). The MCU appears working well with the last downloaded image, but the SWD access seems disabled. Moreover the MCU is able to enter UART ISP Boot (by pulling down a specific ISP pin) and I can erase and rewrite the internal Flash by UART. I tried to connect by SWD even when the MCU has booted in ISP Boot ROM, without any success. Ok, something went wrong with this MCU, it could happen on prototypes during development. But the big issue I am worried about and that is incredible for me, is that this exactly sequence of events happened for one prototype of PCB1, one of PCB2 and one of PCB3!!! After some program&debug cycle (for a few days all is ok), the probe isn't able to connect to the target anymore. The probe and cables seem ok, because if I replace bricked PCBs with a working PCB, all is ok. I tried to contact NXP support, but they couldn't solve this problem and don't know what happened to bricked MCUs. LPC546xx MCUs have a complex mechanism (some values at specific address in the Flash and OTP memory) that allows to restrict access via ISP and/or SWD, but LPC5410x is much more simple. The protection is enabled by writing some magic words at specific address in the internal Flash. However I'm able to erase the internal Flash (by UART ISP) so this can't be the reason of SWD issue. For what I have read, there's now way to lock SWD access after an erase of internal Flash memory. I used J-Link with LPC17xx for many years in the past without any issue. What's the problem with LPC54? Do you have some suggestions?
Cortex-Mx MCUs with SWD access locked
Started by ●June 23, 2022
Reply by ●June 24, 20222022-06-24
Il 23/06/2022 23:38, pozz ha scritto:> Do you have some suggestions?Today I found that SWDIO signal isn't able to swing normally between GND and VDD on broken MCUs. I suspect something bad occurred inside the MCU, but it's strange it happened on three different boards with three different MCUs. Could it be ESD?
Reply by ●June 24, 20222022-06-24
Un bel giorno pozz digit�:>> Do you have some suggestions? > > Today I found that SWDIO signal isn't able to swing normally between GND > and VDD on broken MCUs. I suspect something bad occurred inside the MCU, > but it's strange it happened on three different boards with three > different MCUs. > > Could it be ESD?Or maybe some ground loops, for example if you have connected the J-Link probe to a desktop PC (or in general a PC not isolated from mains) and your boards are somewhat connected to mains or earth ground too. Note that laptops with the charger plugged in are not perflectly isolated from mains either. I've experienced noise problems in several occasions with JTAG probes connected to laptops with the charger plugged in. The noise disappeared just by unplugging the charger. -- Fletto i muscoli e sono nel vuoto.
Reply by ●June 24, 20222022-06-24
On 24/06/2022 11:25, pozz wrote:> Il 23/06/2022 23:38, pozz ha scritto: >> Do you have some suggestions? > > Today I found that SWDIO signal isn't able to swing normally between GND > and VDD on broken MCUs. I suspect something bad occurred inside the MCU, > but it's strange it happened on three different boards with three > different MCUs. > > Could it be ESD?I don't know these particular microcontrollers in detail, but there are two things that can cause problems with debugging that I can think of. One is that you can often re-use the pin as a GPIO. If your program re-uses the debug pins as GPIO, then maybe this is happening before the debugger can get access. The debugger should be able to fix this if it has access to a hard reset pin, but some setups are missing that. The other is that sometimes you can disable the debugger for security reasons. I've done that by accident on a microcontroller (an AVR, IIRC). Of course you could always have had damage from ground loops, spikes when plugging the debugger in and out (if power is on), short-circuits when trying to use an oscilloscope probe with clumsy fingers, etc. If you have access to an X-Ray machine, you might be able to get some idea about what happened.
Reply by ●June 24, 20222022-06-24
Il 24/06/2022 14:15, David Brown ha scritto:> On 24/06/2022 11:25, pozz wrote: >> Il 23/06/2022 23:38, pozz ha scritto: >>> Do you have some suggestions? >> >> Today I found that SWDIO signal isn't able to swing normally between >> GND and VDD on broken MCUs. I suspect something bad occurred inside >> the MCU, but it's strange it happened on three different boards with >> three different MCUs. >> >> Could it be ESD? > > I don't know these particular microcontrollers in detail, but there are > two things that can cause problems with debugging that I can think of. > > One is that you can often re-use the pin as a GPIO. If your program > re-uses the debug pins as GPIO, then maybe this is happening before the > debugger can get access. The debugger should be able to fix this if it > has access to a hard reset pin, but some setups are missing that.Yes I know that, but these microcontrollers can be booted into ISP UART mode by pulling down a pin at power up. When the MCU is in ISP mode, your application doesn't started so the pins stay configured as per their default, so SWD pins are SWD configured. In my case, these MCUs enter ISP mode normally (I can send ISP commands and receive replies), but even in this state the debugger can't connect via SWD.> The other is that sometimes you can disable the debugger for security > reasons. I've done that by accident on a microcontroller (an AVR, IIRC).Yes I know that too. LPC546XX MCUs are complex on this topic, but LPC541XX MCUs are very simple. You can restrict SWD access by writing magic values on certain positions. However I can erase the entire Flash through ISP commands, so after erasing all restrictions should be disabled.> Of course you could always have had damage from ground loops, spikes > when plugging the debugger in and out (if power is on), short-circuits > when trying to use an oscilloscope probe with clumsy fingers, etc. If > you have access to an X-Ray machine, you might be able to get some idea > about what happened.I admit I don't have professional workbench with anti-static writ strap band and so on, but I worked for many years without these kind of problems. It's strange I encountered so many problems concentrated in a few weeks. I will understand the problem of ground loops.
Reply by ●June 24, 20222022-06-24
Il 24/06/2022 12:22, dalai lamah ha scritto:> Un bel giorno pozz digitò: > >>> Do you have some suggestions? >> >> Today I found that SWDIO signal isn't able to swing normally between GND >> and VDD on broken MCUs. I suspect something bad occurred inside the MCU, >> but it's strange it happened on three different boards with three >> different MCUs. >> >> Could it be ESD? > > Or maybe some ground loops, for example if you have connected the J-Link > probe to a desktop PC (or in general a PC not isolated from mains) and your > boards are somewhat connected to mains or earth ground too.Yes, I use a desktop PC connected to mains and the boards are supplied from an AC/DC connected to mains too. Is this a problematic scenario?> Note that laptops with the charger plugged in are not perflectly isolated > from mains either. I've experienced noise problems in several occasions > with JTAG probes connected to laptops with the charger plugged in. The > noise disappeared just by unplugging the charger. >
Reply by ●June 24, 20222022-06-24
Un bel giorno pozz digit�:>> Or maybe some ground loops, for example if you have connected the J-Link >> probe to a desktop PC (or in general a PC not isolated from mains) and your >> boards are somewhat connected to mains or earth ground too. > > Yes, I use a desktop PC connected to mains and the boards are supplied > from an AC/DC connected to mains too. > > Is this a problematic scenario?Normally it shouldn't be, but it also depends on what the board does. If it contains some power stages running at high frequency, it is quite common (especially if the EMI filtering is subpar) that switching currents can pass through the AC/DC power supply and create problems. If this keeps happening, try using a laptop isolated from mains and see if it helps. -- Fletto i muscoli e sono nel vuoto.
Reply by ●June 24, 20222022-06-24
Il 24/06/2022 16:42, dalai lamah ha scritto:> Un bel giorno pozz digitò: > >>> Or maybe some ground loops, for example if you have connected the J-Link >>> probe to a desktop PC (or in general a PC not isolated from mains) and your >>> boards are somewhat connected to mains or earth ground too. >> >> Yes, I use a desktop PC connected to mains and the boards are supplied >> from an AC/DC connected to mains too. >> >> Is this a problematic scenario? > > Normally it shouldn't be, but it also depends on what the board does. If it > contains some power stages running at high frequency, it is quite common > (especially if the EMI filtering is subpar) that switching currents can > pass through the AC/DC power supply and create problems.The target board power input is 12Vdc and on-board DC/DC (TPS54231, 570kHz) generates a single 3.3V.> If this keeps happening, try using a laptop isolated from mains and see if > it helps.I hate laptop as development machine, I will try some USB and/or debugger isolator. However I imaging the problem would arise with oscilloscope, UART/USB converter and so on.
Reply by ●June 24, 20222022-06-24
Un bel giorno pozz digit�:>> If this keeps happening, try using a laptop isolated from mains and see if >> it helps. > > I hate laptop as development machine, I will try some USB and/or > debugger isolator. However I imaging the problem would arise with > oscilloscope, UART/USB converter and so on.Maybe, but the peculiarity of the JTAG probe is that it is usually connected directly to the CPU. Therefore the loop currents may close directly through the CPU pins, which are quite susceptible to this kind of things. This is the reason why sometimes it can be useful to place a buffer (i.e. 74lcx244 or similar) between the probe and the CPU. This may not solve the problem, but even in the case of a failure you will have to replace just an inexpensive buffer instead of the entire CPU. -- Fletto i muscoli e sono nel vuoto.
Reply by ●June 24, 20222022-06-24
On 24/06/2022 16:42, dalai lamah wrote:> Un bel giorno pozz digitò: > >>> Or maybe some ground loops, for example if you have connected the J-Link >>> probe to a desktop PC (or in general a PC not isolated from mains) and your >>> boards are somewhat connected to mains or earth ground too. >> >> Yes, I use a desktop PC connected to mains and the boards are supplied >> from an AC/DC connected to mains too. >> >> Is this a problematic scenario? > > Normally it shouldn't be, but it also depends on what the board does. If it > contains some power stages running at high frequency, it is quite common > (especially if the EMI filtering is subpar) that switching currents can > pass through the AC/DC power supply and create problems. > > If this keeps happening, try using a laptop isolated from mains and see if > it helps. >Another trick is to make sure you have a separate ground connection between the board and the PC before attaching the JTAG. A wire from the board ground to the PC's case is usually fine.
