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

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

RomainP — Thu, 07 Mar 2019 13:47:54 GMT

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.

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

Håkon Alseth — Tue, 05 Feb 2019 08:31:37 GMT

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

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

RomainP — Mon, 04 Feb 2019 16:21:22 GMT

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.

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

Håkon Alseth — Mon, 04 Feb 2019 13:34:25 GMT

Hi Romain,

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

Kind regards,

Håkon

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

RomainP — Thu, 31 Jan 2019 14:23:33 GMT

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.

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

Håkon Alseth — Thu, 31 Jan 2019 12:45:27 GMT

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

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

RomainP — Thu, 31 Jan 2019 08:53:47 GMT

Hi,

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

Best regards,

Romain.

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

Håkon Alseth — Wed, 30 Jan 2019 15:20:47 GMT

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

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

RomainP — Tue, 29 Jan 2019 16:48:12 GMT

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.

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

Håkon Alseth — Tue, 29 Jan 2019 15:22:29 GMT

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

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

RomainP — Mon, 28 Jan 2019 13:34:21 GMT

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 ?

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

Håkon Alseth — Mon, 28 Jan 2019 13:27:52 GMT

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

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

RomainP — Mon, 28 Jan 2019 13:17:34 GMT

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.

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

Håkon Alseth — Mon, 28 Jan 2019 13:05:31 GMT

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

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

RomainP — Mon, 28 Jan 2019 12:54:15 GMT

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.

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

Håkon Alseth — Mon, 28 Jan 2019 12:48:57 GMT

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