How To Remove Debug Interface on NRF52832

[Sami]

Hello,

I can successfully put my nRF52832 into System OFF mode, however, the Debug Mode Interface is still running, so the current consumption is > 2mA. What are the command(s)/Soft Device APIs to truly take the system out of Debug Mode? I'm using SDK v11.0.0 and S132. I'm reading a lot of information on other posts, but none that pertain to SDK v11.0.0 with the Soft Device running S132. Please assist, thank you. 

Please note, I've already tried removing all the debug hardware and battery after flashing and re-attaching the battery, but still not getting the correct results. Thanks!

Best,

Sami

[Jared]

Hi,

Are you using a custom board? sd_flash_protect are used to set the flash protection config registers.

regards

Jared

[Sami]

Yes, I am using a custom board. I thought we use sd_flash_protect() to write to the UCIR register to take the nRF out of debug mode interface by writing

"NRF_UICR->APPROTECT = 0xFF"

What is the proper way to take the nRF52832 out of debug mode interface? Maybe sd_flash_protect() is not the correct API? I'm using SDK v11.0.0.

[Jared]

Hi,

The nRF52 should go into normal mode when it's has been power recycled. How do you know that it's still in DEBUG mode? Are you able to reproduce the same issue with the DK? 

Jared

[Sami]

Yes, after flashing the device, we're issuing a reset to ensure that the device is no longer in debug interface mode (just in case). The premise behind my question: I'm putting my nRF into System OFF mode via a call to: 

uint32_t errCode = sd_power_system_off();

However, the current consumption is still ~2.5mA. After peeling through various threads, lots of responses have said that the nRF is still in debug interface mode. I thought that I had to issue a special command to get it out of debug interface mode in order to achieve truly low current consumption of ~1.5uA. 

Anyway, before entering System OFF mode, I'm terminating EasyDMA (including the Software work-around to power flush TWIM and SPIM as per errata) and shutting down peripherals, but still getting a large current draw. Do I need to pull any other GPIOs low or explicitly halt the HFCLK?  Any assistance would be greatly appreciated.

[Nguyen Hoan Hoang]

First thing first.  Have you validated your hardware against leakage ? have you made any measurement to check that ? Here is how to qualify your hardware for low power.

Make a firmware with just main function with while (1) { __WFE();}.  just that no softdevice. Remove swd connection, power cycle.  Check current.  It should not be less than 10uA.  If more than that, your hardware is leaking.  Next step is to find out what leaks.  This is done by configuring GPIO that are connected to something and the devices that are connected.  You might need to remove suspected components one by one to find the leaks.

[Jared]

Hi,

I understand. I'm still not sure that the device is in debug mode. I would like to reproduce this myself. Could you share a pre-compiled hex file of the application and the softdevice version that you're using? 

regards

Jared 

[Sami]

Thank you Nguyen, my next analysis is to characterize leaks on my custom board.

Jared, unfortunately, I cannot send my .hex file. Can't you check debug mode with a read on

DWT->CYCCNT ?

Also, don't I need to call 

  this: gpio_interrupt_disable();

or

this: nrf_gpio_input_disconnect();

on all non-used GPIOs that while I'm in System OFF mode?

[Sami]

     nrf_gpio_input_disconnect( pinID ); // Currently calling this

     gpio_interrupt_disable( pinID );       // Currently calling this

     nrf_drv_gpiote_in_uninit( pinID );    // Currently calling this

[Jared]

Hi,

I'm not sure if it only specifies if the probes are connected to the SWD interface or also if it's in debug mode. Could you try flashing your custom board with the Power Profiling application and see what current consumption you measure? Could you also describe how you measure the current in more detail?

Yes, you should set the GPIO pins as inputs and de initialize the GPIO buffer. This will prevent the GPIO pins from floating. You can read the state of each GPIO pins by reading the PIN_CNF[N] registers.

regards

Jared

[Sami]

Oh, then my code is incorrect? You mention that I need to set the GPIO pins as inputs. Therefore I need to remove my call to nrf_gpio_input_disconnect( pinID ) and replace with: 

nrf_gpio_cfg_watcher( pinID ); // Set GPIO pins as inputs

gpio_interrupt_disable( pinID ); // Disable interrupts

nrf_drv_gpiote_in_uninit( pinID ); // Uninitialize

Can you please confirm? Thanks!

[RK]

one question - are you just doing a soft reset after flashing or have you tried completely power cycling the board by removing and re-attaching power? It's never been clear to me that a soft reset resets the debug interface. 

[Sami]

RK, I have physically performed a hard reset on the board, removed all debug (SWD) connections and UART connections, and removed re-attached the battery. That should do the trick according to the Nordic Application engineers.