freertos with wdt reset problem, nrfjprog

[twittich]

Hello

my setup is a nrf52840, the sdk15.3, Softdevice s140.

I'm running an application with freertos and wdt and have the openbootloader and s140 also flashed.

- if in freertos the wdt is disabled and i set the GPREGRET register and make a reset with NVIC_SystemReset, i have to make a reset from outside by nrfjprog -r over jlink and then the dfu device comes up...

- and after update the device over dfu it has to be reset by nrfjprog -r and it resetarts in application as wanted

- If the wdt is enabled and do the same, set the GPREGRET register and make a reset with NVIC_SystemReset, the device restarts in application....

How can i make a reset or restart similar to nrfjprog -r from software so that no jlink is needed ?

Thanks in advance

twittich

[Vidar Berg]

Hello Twittich,

The WD timer is not reset through a NVIC_SystemReset (Reset behavior) so it will keep running on subsequent startup when the program enters DFU mode inside the bootloader.  The bootloader feeds the WD by default for this reason. But you may need to adjust the reload interval if you have a short timeout, see NRF_BL_WDT_MAX_SCHEDULER_LATENCY_MS in the bootloader's sdk_config.h file. 

[twittich]

Hello

Thank you. This i tested already but it's still the same. While debugging the bootloader at the function

static bool dfu_enter_check(void)

it's not entering in the following

   if (NRF_BL_DFU_ENTER_METHOD_GPREGRET &&
       (nrf_power_gpregret_get() & BOOTLOADER_DFU_START))
    {
        NRF_LOG_DEBUG("DFU mode requested via GPREGRET.");
        return true;
    }

the problem is at

nrf_power_gpregret_get()

i'm not getting 0xb1 .  If I set this hardcoded to 0xb1 it's starting in dfu mode.....

But in the application i'm setting it and then make a reset.

Can I use the sd functions ?

sd_power_gpregret_set(0,0xB1);
sd_nvic_SystemReset();

Or use the GPREGRET2 and change that in the application and bootloader ?

And regarding the reset of the device after the dfu and update, any idea ?

Thank you for any help....

twittich

[Vidar Berg]

Hello,

The retention register will be read as zero if you have a WD reset occurring before the bootloader has had time to read back the flag. So could it be possible that you get a timeout? As a test, can you increase the reload interval when you initialize it in the app to >5 seconds and see if you get the same result? What is your current timeout?   

[twittich]

Yes i had set it already to 15 and 30 secs but still no difference, the timeout which should be used in future is 1.5 sec if possible.
Do you mean when i make a wd reset (feed the dog) the register is affected or when the wd time out?

[Vidar Berg]

I meant to say that the retention register will be reset if you let the WD timer time out (i.e., not reloaded in time). I'm not sure why you still see this with a timeout of 15-30 seconds though. Can you check the RESETREAS register in the bootloader on startup and see if the 'Reset from watchdog detected' bit is set? 

[twittich]

Ok, i thought so. I'm one step further.

Vidar Berg said:

The bootloader feeds the WD by default for this reason

The bootloader isn't feeding the WD, the device stays in the bootloader and is waiting to start the update process ( the inactivity timeout is set to 0 ) until the wd timeout . If i start the update process then it's feeded and the update proceeds as normal.

But it's strange that i have to make a reset over "nrfjprog -r" then the dfu device comes up. There is no difference if i use "NVIC_SystemReset();" or "sd_nvic_SystemReset();"

Can the function "nrfjprog -r" be reconstructed by software?

[Vidar Berg]

Glad to hear that you had some progress.

twittich said:

But it's strange that i have to make a reset over "nrfjprog -r" then the dfu device comes up. There is no difference if i use "NVIC_SystemReset();" or "sd_nvic_SystemReset();"

I agree it is strange. But are you testing this on a custom board? In that case, have you tried the same on a DK? The only difference I can think of is that nrfjprog -r will put the chip in debug interface mode for a brief moment in order to obtain write access to the reset register.

  

[twittich]

Yes it's a custom board but what could be the problem with it ?

How can i make a soft reset via CTRL-AP ?

Vidar Berg said:

nrfjprog -r will put the chip in debug interface mode for a brief moment in order to obtain write access to the reset register

Means, what can i do to get this by software ?

It's always working: if i set the gpregret, (this i forgot to write -> ) make aftwards a "self reset" by a gpio which triggers the nreset and then over terminal the nrfjprog -r. .

[Vidar Berg]

twittich said:

Means, what can i do to get this by software ?

 It may be possible to do enable the debug interface and do this in SW, it is something I could look into. But I don't think it's good a solution to the problem. And it would be good to understand what's causing this. I tried to through the case again to see if I've overlooked something and realize now that you seem to get similar behavior without the WDT enabled as well? I thought it was only with when you had WDT enabled.

^^

- if in freertos the wdt is disabled and i set the GPREGRET register and make a reset with NVIC_SystemReset, i have to make a reset from outside by nrfjprog -r over jlink and then the dfu device comes up...

twittich said:

But it's strange that i have to make a reset over "nrfjprog -r" then the dfu device comes up. There is no difference if i use "NVIC_SystemReset();" or "sd_nvic_SystemReset();"

 What happens if you debug the bootloader project while you perform your grepregret->nvic_systemreset() sequence from the app? Is the bootloader program getting stuck in a loop somewhere? Do you need to do a reset for it to become discoverable on Bluetooth?

[twittich]

At the beginning the timeout time wasn't changed, it was still set to 1.5 sec which is way too less. So for now it makes no difference if enabled or disabled because it's set it to 50 sec. I know now that i have to feed the wd from beginning on in the bootloader so this i'll change later.

Vidar Berg said:

 It may be possible to do enable the debug interface and do this in SW, it is something I could look into.

If you could tell me a first solution would be great, afterwards it can always be changed.

Vidar Berg said:

debug the bootloader project

This i'll check now ....