Using SWDIO/CLK as GPIO breaks debug?

[brentsinger]

Hi,

I'm reasonably new to MCU Expresso and LPC8 family. 

I was using CTIMER1 on my LPC8N04 and routed the match0 pin to SWCLK, thinking that the 'do nothing' selection might not do anything. I'm using the LPC8N04 dev board OM40002.

I immediately lost debug, and the probe can't speak with the target at all. MCU Expresso is giving me error after error.

I fear I've bricked the dev board. How do I get it back?

The 8N04 doesn't have an ISP pin...

Thanks in advance.

Brent.

[brentsinger]

I can't think of a single micro I've worked with that allows you to brick a part this easily. My last project was on psoc4 and it will happily let you repurpose the swd pins for IO. you don't lose SWO, and you can flash the device with no issue. You just lose the ability to emulate/debug probe. To recover, you just tell the IDE you want those pins back, and upload to flash. voila, you have your debug module back.

at the very least the IDE should let you know with a warning or a pop-up that you will not get to flash this part again (unless you have a PE micro probe.)

Anyhow, I wasn't able to get the mculink to catch the part. I've ordered another OM30002 from digikey.

But on another note; Is it worth me buying a multi-link for a better user experience? Is it much different to the mcu-link or embedded debugger NXP bundles on most dev boards? mcu-link is meeting my needs, but better is better and I'll pay for better tools.

Thanks again for your generous help.

[ErichStyger]

Hi @brentsinger ,

I have managed to recover some of my boards using a script running with the LinkServer (McuLink/McuLink Pro or LPC-Link). I just published an article about it here:

https://mcuoneclipse.com/2023/07/25/linkserver-scripting-and-how-to-recover-mcus-with-a-script/

It uses a similar approach as the PEMICRO probe: the script runs in a loop and tries to halt processor out of reset. I recommend that you give this a try.

[ErichStyger]

About debug probes:

I always have different debug probes around, e.g. MCU-Link(s), J-Link(s) and P&E Multilink(s), and using different connections (proprietary, OpenOCD, pyOCD, ARM DAPLink, ...). It is less about usability, but every vendor has its own pros and cons. And I found (like in this case discussed) not every thing is supported well by every vendor. So having different tools on my desk helps to solve all kind of problems.

[ErichStyger]

Hi Brent,

if changing/disabling/affecting the debug SWD pins, then you cut the debug block and render it as not accessible.

As you did make the change in your application code, you need now to regain access to the device running from the startup prior it does that change in your code.

You will need a fast debug probe able to 'catch' the device. What I have done in the past is using an external PEMICRO debug probe (see https://mcuoneclipse.com/2021/05/20/recovering-cortex-m-microcontroller-with-a-power-glitch/ ) which is able to catch the device during that tiny window. (Note: the PEMCIRO probe seems to implement this only for Kinetis devices)

I hope this helps,

Erich

[brentsinger]

Thanks Erich,

So the debug probe that is part of the dev board is not able to catch and restore the debug module? 

That feels like a design flaw to me NXP... No warning in the manual I can find. Perhaps a warning or information about what happens when you repurpose the SWD as GPIO...

Just to confirm, this is ALL I did to cause the issue. Simply CTIMER1 Match routed to pin 15 SWDIO. 

I have an MCU Link probe, and I have a Segger Jlink dongle. Would either of these tools be quick enough? 

Cheers,

Brent.

[xiangjun_rong]

Hi,

As Erich said that the Prob has to capture the device before the application code assigns the PIO0_10/CT32B_M0/SWCLK as function CT32B_M0.

Because the LPC8N04 does not have ISP mode, it deteriorates the scenario, you can not have the pins in the default state.

But I think the key is the prob can capture the device before the application code execute the line to configure the PIO0_10/CT32B_M0/SWCLK after Reset. So you can set up the prob so that it can capture the device as soon as possible after Reset.

1)Pls try to check the box of Reset on connect

2)pls try to press Reset button on the board and and press "Debug"  to download application immediately, and try multiple times and check if you have opportunity.

Hope it is helpful.

BR

XiangJun Rong

[ErichStyger]

You might be lucky if the on-board, MCU-Link or J-Link probe would be able catch your device early enough in the boot process. You might be successful scripting the LinkServer (see https://mcuoneclipse.com/2023/05/14/linkserver-for-microcontrollers/). Far easier should be to use the Multilink. Or simply solder a new part to the board.

I don't agree that this is a design flaw: this is by design and purpose, as that way you have more pins available, and in the case you need to protect against debug access to you IP and board, it is standard procedure to disable the debug pins, even inside the boot ROM. And your screenshot below should already have informed you that you are going to affect the SWDCLK (not the SWDIO)?

I hope this helps,

Erich