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]

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

[RomainP]

Hi, I have test your code and I have the same result.

I doubt is the hardware because when I send this commande by nrfjprog the consumption goes down without hardware reset.

SWDSelect
SWDWriteDP 1 0x04000000
exit

But I will test with unmount all peripheral on my card.

Best regards.
Romain.

[Håkon Alseth]

Hi Romain,

 

Haven't heard anything for some days now. Is the problem still present?

 

Kind regards,

Håkon

[RomainP]

Hi, 

         The problem is still present, I have dismounted all components except NRF52, quartz and cap and it is still present.

         Now I will be off for the next days, I will back to the office on Monday of next week.

So if you have so more tests I will be taking time to answer,

Best regards,

Romain.

[Håkon Alseth]

Hi Romain,

 

Just to confirm what you are seeing here.

1. The current consumption goes high after debug or pinreset (around 2.7 mA)

2. Performing this sequence returns the power consumption to ~2 uA:

SWDSelect
SWDWriteDP 1 0x04000000
exit

3. Simple program that enters __WFE() also consumes ~2.7 mA when reset.

 

Please correct me if I've misunderstood the process, or if there's any mistakes from my side.

Q1: Have you checked if there's any faults occurring (hard fault, usage fault, etc)? This current consumption does not match any idle peripheral currents.

Q2: Do you see this on more than one board? Is this a specific error on one board, or is the phenomenon present on more boards?

Q3: Have you tried implementing blocking fault handlers (that prints or blinks a LED) to see if it goes in? Or blinking a LED in your main-context to see if the program works as it should?

 

Kind regards,

Håkon

[RomainP]

Hi, 

            I find the answer !

  I use J-Link RTT viewer to log the nrf_log_raw_info(), and if this application run on the PC and if you do not a proper disconnect the device, the over consumption appear. So for my prod I just do not have to lunch the RTT viewer.

Thanks for your help,

Best regards,

Romain.