Over consumption just after a flash and no problem after an hardware reset

[RomainP]

Hi,

           Recently I have migrated my app of SDK13 to SDK15.2. It's a little bit complicate but it works with patience, thanks for the migration guide !

My problem now is when I flash my app with the new software, the consumption is about ~2.7mA and after a hardware RESET (cut the power) is just few µA. I flash my own board with KEIL MDK 5, with an NRF52832 eval KIT.

         For the migration I have re-create my project with BLE_APP_BLINKY for restart with a proper base. I have tests to make a NVIC_systeme_reset, a watchdog reset and reset with nrfjprog : rfjprg --family NRF52 -r but no manipulation goes to work.

I see this post : https://devzone.nordicsemi.com/f/nordic-q-a/27255/resetting-dif-to-reduce-interface-current-on-nrf52/107583#107583

And if I make the same manip is working but I would understand what can cause the problem in my code.

Before the changing of the SDK, I had made a BASH script to programme few cards directly and I have the same problem now with this new HEX and with the old HEX and now I'm not sure if I have the problem before. I'm sorry if it's a little bit confuse but this debug wash my brain ...

If someone can help, I will be very grateful !

Regards, Romain. 

Build OUTPUT : 

JLink info:
------------
DLL: V6.34g, compiled Sep 26 2018 14:45:08
Firmware: J-Link OB-SAM3U128-V2-NordicSemi compiled Jul 12 2018 11:44:41
Hardware: V1.00
S/N : 682779794 
 
* JLink Info: Found SW-DP with ID 0x2BA01477
* JLink Info: Found SW-DP with ID 0x2BA01477
* JLink Info: Scanning AP map to find all available APs
* JLink Info: AP[2]: Stopped AP scan as end of AP map has been reached
* JLink Info: AP[0]: AHB-AP (IDR: 0x24770011)
* JLink Info: AP[1]: JTAG-AP (IDR: 0x02880000)
* JLink Info: Iterating through AP map to find AHB-AP to use
* JLink Info: AP[0]: Core found
* JLink Info: AP[0]: AHB-AP ROM base: 0xE00FF000
* JLink Info: CPUID register: 0x410FC241. Implementer code: 0x41 (ARM)
* JLink Info: Found Cortex-M4 r0p1, Little endian.
* JLink Info: FPUnit: 6 code (BP) slots and 2 literal slots
* JLink Info: CoreSight components:
* JLink Info: ROMTbl[0] @ E00FF000
* JLink Info: ROMTbl[0][0]: E000E000, CID: B105E00D, PID: 000BB00C SCS-M7
* JLink Info: ROMTbl[0][1]: E0001000, CID: B105E00D, PID: 003BB002 DWT
* JLink Info: ROMTbl[0][2]: E0002000, CID: B105E00D, PID: 002BB003 FPB
* JLink Info: ROMTbl[0][3]: E0000000, CID: B105E00D, PID: 003BB001 ITM
* JLink Info: ROMTbl[0][4]: E0040000, CID: B105900D, PID: 000BB9A1 TPIU
* JLink Info: ROMTbl[0][5]: E0041000, CID: B105900D, PID: 000BB925 ETM
ROMTableAddr = 0xE00FF000
* JLink Info: Reset: Halt core after reset via DEMCR.VC_CORERESET.
* JLink Info: Reset: Reset device via reset pin
* JLink Info: Reset: VC_CORERESET did not halt CPU. (Debug logic also reset by reset pin?).
* JLink Info: Reset: Reconnecting and manually halting CPU.
* JLink Info: Found SW-DP with ID 0x2BA01477
* JLink Info: AP map detection skipped. Manually configured AP map found.
* JLink Info: AP[0]: AHB-AP (IDR: Not set)
* JLink Info: AP[0]: Core found
* JLink Info: AP[0]: AHB-AP ROM base: 0xE00FF000
* JLink Info: CPUID register: 0x410FC241. Implementer code: 0x41 (ARM)
* JLink Info: Found Cortex-M4 r0p1, Little endian.
* JLink Info: Reset: Halt core after reset via DEMCR.VC_CORERESET.
* JLink Info: Reset: Reset device via AIRCR.VECTRESET.
 
Target info:
------------
Device: nRF52832_xxAA
VTarget = 3.300V
State of Pins: 
TCK: 0, TDI: 1, TDO: 1, TMS: 1, TRES: 1, TRST: 1
Hardware-Breakpoints: 6
Software-Breakpoints: 8192
Watchpoints:          4
JTAG speed: 1000 kHz
 
Erase Done.
Programming Done.
Verify OK.
* JLink Info: Reset: Halt core after reset via DEMCR.VC_CORERESET.
* JLink Info: Reset: Reset device via reset pin
* JLink Info: Reset: VC_CORERESET did not halt CPU. (Debug logic also reset by reset pin?).
* JLink Info: Reset: Reconnecting and manually halting CPU.
* JLink Info: Found SW-DP with ID 0x2BA01477
* JLink Info: AP map detection skipped. Manually configured AP map found.
* JLink Info: AP[0]: AHB-AP (IDR: Not set)
* JLink Info: AP[0]: Core found
* JLink Info: AP[0]: AHB-AP ROM base: 0xE00FF000
* JLink Info: CPUID register: 0x410FC241. Implementer code: 0x41 (ARM)
* JLink Info: Found Cortex-M4 r0p1, Little endian.
* JLink Info: Reset: Halt core after reset via DEMCR.VC_CORERESET.
* JLink Info: Reset: Reset device via AIRCR.VECTRESET.
Application running ...
Flash Load finished at 12:25:26

[Håkon Alseth]

Hi,

 

When programming, the nRF is usually left in a halted state. A reset (or a run) will allow it to start CPU execution again.

You can either do a reset, or a run to start your application after programming.

 

Kind regards,

Håkon

[RomainP]

Hi, 

          I do a reset, so Keil do it and the programme RUN, and in my bash program I use this command : 

nrfjprog --family NRF52 --reset at the end to start the application.

The application run but with some mA add to the normal consumption.

Best regards,

Romain.

[Håkon Alseth]

Is there anything on your own board that may go into a high-current consumption state if the nRF is reset, and not the rest of the board? Like an accelerometer or similar?

Kind regards,

Håkon

[RomainP]

I don't think so, because when I made this with Nrfjprog 

SWDSelect
SWDWriteDP 1 0x04000000
exit

The power pass to ~2µA.

Best regards,
Romain.

[Håkon Alseth]

Have you readback protected your device? If yes; then only a set of reset commands are available per the nrfjprog help output.

     --rbp <level>           Enables the readback protection mechanism. Valid
                             argument options are CR0 and ALL.
                             Limitations:
                             For nRF52 devices, the CR0 argument option is
                             invalid.
                             Side effects:
                             After an --rbp operation is performed, the
                             available operations are reduced.
                             For nRF51 devices, and if argument option ALL is
                             used, --pinreset will not work on certain older
                             devices.
                             For nRF52 devices, only --pinreset, --debugreset
                             or --recover operations are available after --rbp.

Kind regards,

Håkon

[RomainP]

On my bash script, I'm not using "--rbp" I'm used : 

nrfjprog --family NRF52 --program app_thingy_s132.hex --verify

I don't know if it is active in default.

On KEIL, it's the default project I don't know where I can check that could say to me where I can check ?

[Håkon Alseth]

Hi,

 

Keil does not have the option to set readback protection.

If you do not set "--rbp", then its not readback protected, so all reset sources should be available (including pin-reset if enabled).

Could you show the whole script that you are running?

Kind regards,

Håkon

[RomainP]

Hi,

       I can't supply all my script but I can send you all the command send to the nrfJprog :

nrfjprog --eraseall
nrfjprog --family NRF52 --program sofDeviceFiles.hex --chiperase --verify
nrfjprog --family NRF52 --program bootloaderFiles.hex --verify --quiet
nrfjprog --family NRF52 --program applicationFiles.hex --verify --quiet
nrfjprog --family NRF52 --reset

Best regards,

Romain.

[Håkon Alseth]

Hi,

 

I do not see any issues with the commands that you are using. This should give you a low power consumption and detach the debugger IF.

Could you ensure that you have the latest JLink Segger drivers (downloadable from here: https://www.segger.com/downloads/jlink/#J-LinkSoftwareAndDocumentationPack)

and the latest nrfjprog version downloadable from here: https://www.nordicsemi.com/Software-and-Tools/Development-Tools/nRF5-Command-Line-Tools

Then try to see if there's any difference?

 

Kind regards,

Håkon 

[RomainP]

Hi,

          I have made the upgrade of two programs and delete the old version and nothing change.

Best regards,

Romain.

[Håkon Alseth]

Hi,

 

I've tried to replicate this with similar commands as you are using (in ubuntu 18.10), but it goes into < 5 uA sleep mode at my end. Also tried starting up the JLinkGDBServer and exiting it to see if this leaves the DIF in a power hungry state, but the current consumption still dropped.

Is it possible that there's something else on your board that is in a configured state after the nRF is reset?

 

Could you try programming your application with a simple while loop with WFE, just to see if the setup is OK? Here's a modified peripherals/blinky:

int main(void)
{
    /* Configure board. */
    bsp_board_init(BSP_INIT_LEDS);
    for (int i = 0; i < LEDS_NUMBER; i++)
    {
        bsp_board_led_invert(i);
        nrf_delay_ms(500);
    }
    /* Toggle LEDs. */
    while (true)
    {
        __WFE();
    }
}

Blinky can be offset to accommodate the softdevice (../blinky/pca10040/s132/). 

 

Kind regards,

Håkon