SWD / GPIO: Avoiding Conflict (NHS3152 + LPC-Link2)

[jesmith]

I'm developing an application that uses the NHS3152 and want to utilize PIO0_10 (SWCLK) and PIO0_11 (SWDIO) as GPIO pins in the context of said application, but retain the ability to program (not necessarily debug) the controller over SWD using the LPC-Link2. 

Presumably, this is possible, because the FUNC bit has the option to choose, but I'm concerned that if the controller is programmed to switch the SWD pins to GPIO pins, the controller may not be able to be programmed any longer. 

What steps do I need to take to avoid conflict between the split utility of this pins? 

Are there internal pull-ups / downs on these pins that define their default state during start-up?

Thanks!

[patrickgeens · Accepted solution]

Hello jesmith,

At start, the SWD pins are input mode and floating. When the chip comes out of reset, a small bootloader runs to prepare the hardware blocks and check the CRP (code read protection) bits. If allowed by the CRP code, it sets the PIO0_10/11 FUNC bits to select SWD function, no pull-ups or pull-downs. It then starts the user code in flash.

To allow dual use of PIO0_10 and PIO00_11 there are several options:

- have a large enough time window between the start of user code and changing the FUNC bits of the SWD pins, to allow the SWD programmer to halt the ARM core before the firmware disables SWD. Possibly an extra delay loop is needed. Both SWD pins and nRESET pin must be connected to the LPC-LINK2 or other SWD dongles.

- read the state of a PIO pin(s) at startup and use that to conditionally enable SWD

- use CRP2 mode: when PIO0_1 (ISP pin) is low during boot, the bootloader will erase the flash and enable SWD

- when using NFC and the "msg" handler from the SDK:
set MSG_ENABLE_PREPAREDEBUG to 1. (see app_sel.h and mods/msg/msg.c)
When the corresponding NFC message is received, the handler code enables SWD and goes in a wait loop.
In the demo applications this setting is done in "app_sel.h" if DEBUG is defined.
*NOT* to be used in final firmware (Release build) as it defeats the purpose of code read protection and enables wireless denial of service.

Kind regards,

Patrick

[jesmith]

For the option involving a "sufficient" delay on startup before changing the FUNC bits — what constitutes a sufficient delay? My application isn't time sensitive, so I don't mind waiting, but I don't want to needlessly select a long delay that will slow down development time nor accidentally lock myself out of a development board. 

TIA!

[patrickgeens]

Hello jesmith,

Timing depends on the debugger/flasher software and firmware loaded in the LPC-LINK2.

I have measured values between 50ms and 100ms between end-of-reset and SWD communication.

A delay of 200ms is probably a safe and acceptable startup delay.

Kind regards,

Patrick