• State Not Answered
  • Replies 14 replies
  • Subscribers 74 subscribers
  • Views 5511 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 213621
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

how does the nrf52832 decide to enter the swd mode?

cgadgil

hi

my question is really basic, but i am not able to find an answer anywhere else. I am trying to program the nordic using its SWDIO and SWCLK pins and am stuck as i get " emulator not found" error. I am wondering what the problem could be. How does the nrf52832 detect a swd programmer connected and decide to enter the debug mode as against running its existing code if any? 

is a reset or some specific signal on any other pin necessary?

I have used the nrf51822 before and i only connected SWDIO, SWCLK, VCC and GND and everything worked well. but with the nrf52832 i am having issues programming the IC.

thanks in advance for the answer

Parents Reply Children
  • 0 in reply to Håkon Alseth

    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

  • 0 in reply to cgadgil

    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

  • 0 in reply to Håkon Alseth

    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.

  • 0 in reply to cgadgil 
    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()
  • 0 in reply to cgadgil

    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. 

Related
Terms of service