I am using the Segger interface for designing an nRF52 based device. I am planning to use SWDIO SWCLK VTref and GND pins on my device. Is it necessary to connect the nRESET pin to the Reset pin of the NRF52 chip? If I dont connect this, will there be any issue with programming/flashing the device? what are the advantages/disadvantages? Can anyone kindly elaborate on this?
I'm using a nRF51 device with a Keil ulink2 - I just have four wires to the nRF for Ground, Power, SWCLK and SWDIO which works for me (programming soft device, programming application code and debugging…
No - it is not necessary to connect the nRESET pin to the RESET pin on the nRF52 chip.
The nRF51 had a SWD protocol that was not standard - the reset was multiplexed on the SWDIO lines.
This is not the…
I'm using a nRF51 device with a Keil ulink2 - I just have four wires to the nRF for Ground, Power, SWCLK and SWDIO which works for me (programming soft device, programming application code and debugging). My software isn't using any microcontroller sleep modes which have caused me issues on other processors (STM32).
So the nRESET is not necessary.
The nRF51 SWDIO is actually labelled SWDIO/nRESET so I expect that it is possible to reset the debug interface but I haven't had to do that.
I expect that using a Segger interface won't make any difference as the wires are an ARM interface that doesn't care about the brand of debugger being attached.
This is not the case with the nRF52, the SWD interface is standard. Now you have the option to configure a GPIO pin (pin 21 by default) as a reset pin. This is not required though. SEGGER or any other programming tools don't need a reset pin. They reset the device by writing CPU registers and through SWD commands (sysResetReq).
Does the nRF52 SWD have multi-drop support?
no, it does not support this.
Actually, you may have to resort to "hardware" (though software configured) reset if you're using the watchdog, as it isn't stopped by a software reset. The watchdog can be inhibited when the core is halted, but that won't do you any good if your probe (and backing software) loads firmware in RAM along with a microcode tasked with writing it down to flash, or some variant of that. Except if said microcode is smart enough to refresh the watchdog, that is.