how does the nrf52832 decide to enter the swd mode?

RE: how does the nrf52832 decide to enter the swd mode?

Håkon Alseth — Mon, 01 Oct 2018 07:20:02 GMT

Hi,

The nRESET pin should have nothing to do with the programming process, unless you have routed the P0.21 pin to GND (constant reset after programming _if_ nRESET is enabled).

Have you powered your external board with 3.3V? Cheaper debuggers only has a set voltage in which they can program the device successfully on.

Best regards,

Håkon

RE: how does the nrf52832 decide to enter the swd mode?

cgadgil — Thu, 27 Sep 2018 05:58:24 GMT

https://devzone.nordicsemi.com/f/nordic-q-a/37150/nrf52832-disable-reset-pin-segger-embedded-studio

this also seems to help with the issue of programming. i have about 6 custom PCBs with me currently and of them i am able to program about 4 of them using the DK , and tinkering around with the reset pin. Other 2 PCBs still not being detected.

I dont know if buying a segger programmer will solve this issue and if i should invest in the programmer and nrf52832 as such. These issues dont give lot of confidence in the chip

RE: how does the nrf52832 decide to enter the swd mode?

cgadgil — Sat, 15 Sep 2018 09:16:19 GMT

As a side note, nordic can consider bringing out the reset and SWO pins in their reference designs and kept as optional. it will be good heads up for the people using the designs.

RE: how does the nrf52832 decide to enter the swd mode?

cgadgil — Sat, 15 Sep 2018 09:14:54 GMT

i pulled up the reset pin and then tried recover by connecting to the DK. i powered the custom board separately, not from the DK.

Problem solved this way.

I understand DK is not licence for production programming. Which segger part numbers can be used for the Nrf52X ?

RE: how does the nrf52832 decide to enter the swd mode?

RK — Tue, 11 Sep 2018 23:01:44 GMT

have you tried

nrfjprog --recover

because it's possible the debug port is locked and so it won't power up. As far as I can tell from guessing what the logfile means it's trying to do a write to the DP SELECT register which is a fairly basic operation.

RE: how does the nrf52832 decide to enter the swd mode?

cgadgil — Tue, 11 Sep 2018 02:20:42 GMT

yes, i searched for the error i am getting in the log, looks like many such cases for the nrf52.

. . . . nRFXX_write_debug_port_register: JLinkARM.dll CORESIGHT_WriteAPDPReg returned error -1. . . . nRFXX_power_debug_and_system_regions: JLinkARM.dll CORESIGHT_WriteAPDPReg returned error -102.

after this is the device getting "locked" in some way and there is no way to program it using SWD?

Many threads with similar say it many be due to unstable power or RESET pin being not connected.

I tried PCBs with 2 different layouts and power and i do not really doubt power issue on that. The RESET pin however unfortunately i left unused and is not brought out of the QFN. i might have to try and actually solder something on the QFN ic to pull the RESET to 3V.

RE: how does the nrf52832 decide to enter the swd mode?

RK — Mon, 10 Sep 2018 21:38:22 GMT

the processor doesn't detect it - the debugger connects, powers up the debug port which is a separate piece of hardware inside the cortex-M and then halts the processor, or resets it or reads registers. There really isn't a separate debug mode, there's just running with and without the debug port powered up and in-use or not. Of course with the DAP powered bits of the power and clock systems remain running all the time so the chip can't go into low power mode (for instance).

To your point in the next mail - a debugger can't damage the device, so you're getting it into a state it's not being responsive to what you're trying, however it's undamaged.

RE: how does the nrf52832 decide to enter the swd mode?

cgadgil — Mon, 10 Sep 2018 14:49:41 GMT

nrfjprog --eraseall --log
nrfjprog version 9.7.3
--------------------------------------------------------------------------------
nRF_open_dll
. nRFXX_open_dll
. . nRFXX_dll_version
nRF_enum_emu_snr
. nRFXX_enum_emu_snr
nRF_enum_emu_snr
. nRFXX_enum_emu_snr
nRF_connect_to_emu_with_snr
. nRFXX_connect_to_emu_with_snr
. . nRFXX_is_connected_to_emu
. . nRFXX_connect_to_emu_without_snr
. . . nRFXX_is_connected_to_emu
. . . nRFXX_enum_emu_snr
. . nRFXX_connect_to_emu_without_snr:	JLink:	 Firmware: J-Link ARM-OB STM32 compiled Aug 22 2012 19:52:04
. . nRFXX_connect_to_emu_without_snr:	JLink:	 Hardware: V7.00
. . nRFXX_connect_to_emu_without_snr:	JLink:	 S/N: 20151216
. . nRFXX_connect_to_emu_without_snr:	JLink:	 Feature(s): RDI,FlashDL,FlashBP,JFlash,GDBFull
. . nRFXX_connect_to_emu_without_snr:	JLink:	 TELNET listener socket opened on port 19021
. . nRFXX_connect_to_emu_without_snr:	JLink:	WEBSRV  Starting webserver
. . nRFXX_connect_to_emu_without_snr:	JLink:	 (0031ms, 0039ms total)  
. . nRFXX_connect_to_emu_without_snr:	JLink:	WEBSRV Webserver running on local port 19080
. . nRFXX_connect_to_emu_without_snr:	JLink:	 (0034ms, 0042ms total)  
. . nRFXX_connect_to_emu_without_snr:	JLink:	  returns O.K.
. . nRFXX_connect_to_emu_without_snr:	JLink:	 (0037ms, 0045ms total)  
. . nRFXX_connect_to_emu_without_snr:	JLink:	JLINK_GetHWStatus(...)
. . nRFXX_connect_to_emu_without_snr:	JLink:	  returns 0x00
. . nRFXX_connect_to_emu_without_snr:	JLink:	 (0004ms, 0053ms total)  
. . nRFXX_connect_to_emu_without_snr:	JLink:	JLINK_ExecCommand("Device = NRF52832_xxAA", ...). 
. . nRFXX_connect_to_emu_without_snr:	JLink:	C:\Program Files (x86)\SEGGER\JLink_V622g\JLinkDevices.xml evaluated successfully.
. . nRFXX_connect_to_emu_without_snr:	JLink:	Device "NRF52832_XXAA" selected.
. . nRFXX_connect_to_emu_without_snr:	JLink:	Device "NRF52832_XXAA" selected.
. . nRFXX_connect_to_emu_without_snr:	JLink:	  returns 0x00
. . nRFXX_connect_to_emu_without_snr:	JLink:	 (0237ms, 0293ms total)  
. . nRFXX_connect_to_emu_without_snr:	JLink:	JLINK_ExecCommand("SetRestartOnClose = 0", ...). 
. . nRFXX_connect_to_emu_without_snr:	JLink:	  returns 0x01
. . nRFXX_connect_to_emu_without_snr:	JLink:	 (0001ms, 0297ms total)  
. . nRFXX_connect_to_emu_without_snr:	JLink:	JLINK_ExecCommand("DisableFlashDL", ...). 
. . nRFXX_connect_to_emu_without_snr:	JLink:	  returns 0x00
. . nRFXX_connect_to_emu_without_snr:	JLink:	 (0001ms, 0300ms total)  
. . nRFXX_connect_to_emu_without_snr:	JLink:	JLINK_ExecCommand("SetDbgPowerDownOnClose = 1", ...). 
. . nRFXX_connect_to_emu_without_snr:	JLink:	  returns 0x01
. . nRFXX_connect_to_emu_without_snr:	JLink:	 (0001ms, 0303ms total)  
. . nRFXX_connect_to_emu_without_snr:	JLink:	JLINK_ExecCommand("ExcludeFlashCacheRange 0x0-0xFFFFFFFF", ...). 
. . nRFXX_connect_to_emu_without_snr:	JLink:	  returns 0x00
. . nRFXX_connect_to_emu_without_snr:	JLink:	 (0001ms, 0306ms total)  
. . nRFXX_connect_to_emu_without_snr:	JLink:	JLINK_TIF_Select(JLINKARM_TIF_SWD)
. . nRFXX_connect_to_emu_without_snr:	JLink:	  returns 0x00
. . nRFXX_connect_to_emu_without_snr:	JLink:	 (0003ms, 0310ms total)  
. . nRFXX_connect_to_emu_without_snr:	JLink:	JLINK_SetSpeed(2000)
. . nRFXX_connect_to_emu_without_snr:	JLink:	 (0002ms, 0313ms total)  
nRF_read_connected_emu_snr
. nRFXX_read_connected_emu_snr
. . nRFXX_is_connected_to_emu
. . nRFXX_is_connected_to_emu:	JLink:	JLINK_IsOpen()
. . nRFXX_is_connected_to_emu:	JLink:	  returns 0x01
. . nRFXX_is_connected_to_emu:	JLink:	 (0002ms, 0316ms total)  
nRF_read_device_family
. nRFXX_read_device_family
. . nRFXX_is_connected_to_emu
. . nRFXX_is_connected_to_emu:	JLink:	JLINK_IsOpen()
. . nRFXX_is_connected_to_emu:	JLink:	  returns 0x01
. . nRFXX_is_connected_to_emu:	JLink:	 (0003ms, 0320ms total)  
. . nRFXX_read_access_port_register
. . . nRFXX_coresight_configure
. . . nRFXX_coresight_configure:	JLink:	JLINK_CORESIGHT_Configure()
. . . nRFXX_coresight_configure:	JLink:	 >0x10B TIF>
. . . nRFXX_coresight_configure:	JLink:	 >0x10F TIF>
. . . nRFXX_coresight_configure:	JLink:	 >0x0D TIF>
. . . nRFXX_coresight_configure:	JLink:	 >0x0D TIF>
. . . nRFXX_coresight_configure:	JLink:	  returns 0
. . . nRFXX_coresight_configure:	JLink:	 (0009ms, 0330ms total)  
. . . nRFXX_power_debug_and_system_regions
. . . . nRFXX_write_debug_port_register
. . . . nRFXX_write_debug_port_register:	JLink:	JLINK_CORESIGHT_WriteAPDPReg(DP reg 0x02, 0x00000000)
. . . . nRFXX_write_debug_port_register:	JLink:	 >0x0D TIF>
. . . . nRFXX_write_debug_port_register:	JLink:	  returns -1
. . . . nRFXX_write_debug_port_register:	JLink:	 (0004ms, 0336ms total)  
. . . . nRFXX_write_debug_port_register:	JLinkARM.dll CORESIGHT_WriteAPDPReg returned error -1.

. . . nRFXX_power_debug_and_system_regions:	JLinkARM.dll CORESIGHT_WriteAPDPReg returned error -102.

nRF_close_dll
. nRFXX_close_dll
. . nRFXX_is_connected_to_emu
. . nRFXX_is_connected_to_emu:	JLink:	JLINK_IsOpen()
. . nRFXX_is_connected_to_emu:	JLink:	  returns 0x01
. . nRFXX_is_connected_to_emu:	JLink:	 (0002ms, 0339ms total)  
. . nRFXX_disconnect_from_emu
. . nRFXX_disconnect_from_emu:	JLink:	JLINK_Close()

RE: how does the nrf52832 decide to enter the swd mode?

cgadgil — Mon, 10 Sep 2018 14:42:39 GMT

thanks

reading the following gave a clearer picture

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0314h/Babdadfc.html

To update on the programming issue, i tried another set of custom PCB with nrf52832 with same result. The device is initially detected, softdevice is programmed and while downloading the application i get an error. After this happens the my laptop refuses to detect the device. Any subsequent power up cycles and effort to connect to the device fail.

I am afraid my programmer may be damaging my device in some way.

RE: how does the nrf52832 decide to enter the swd mode?

Håkon Alseth — Mon, 10 Sep 2018 13:39:46 GMT

Hi,

The nRF51 has mux'ed the nRESET pin with the SWDIO pin, so the setup there is a bit different to other Cortex M-family devices. The nRF52832 has dedicated SWDIO/SWDCLK pins, thus it uses the standardized ARM DAP to enable the "debugger interface" (DIF). More info can be found in one of our white papers:

http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.whitepapers/dita/whitepapers/nwp_027/intro.html?cp=11_4

Cheers,

Håkon

RE: how does the nrf52832 decide to enter the swd mode?

cgadgil — Mon, 10 Sep 2018 13:34:13 GMT

thanks!

yes it seems so.. i will check with the manufacturer. However i would still want to know the answer to my question "How does the nrf52832 detect a swd programmer connected and decide to enter the debug mode as against running its existing code if any? "

because i am not finding sufficient documentation on the reset process from hardware + firmware perspective at one place

RE: how does the nrf52832 decide to enter the swd mode?

Håkon Alseth — Mon, 10 Sep 2018 13:29:53 GMT

For the specific debugger that you're using, it seems that it has limited support according to this page: https://www.waveshare.com/arm-debugger.htm

It mentions that this only works with the nRF51822 board. I suspect that the manufacturer does not support other devices with this specific programmer, but I would recommend contacting them to double check.

Best regards,

Håkon

RE: how does the nrf52832 decide to enter the swd mode?

cgadgil — Mon, 10 Sep 2018 03:50:11 GMT

https://www.waveshare.com/wiki/ARM_Debugger

Although it does not mention the nordic microcontroller in the supported microcontroller list, since nordic is cortex M4 i believe it should still work?

RE: how does the nrf52832 decide to enter the swd mode?

RK — Mon, 10 Sep 2018 00:33:46 GMT

what In Circuit Emulator or debugger are you using to try and program the chip? Segger? OpenOCD .. what?