Watchdog event handler timeout

[Gueston]

I want to write some values to flash before the watchdog resets. For this I have the watchdog event handler specified:

err_code = nrf_drv_wdt_init(&config, wdt_event_handler);

In the wft_event_handler function I write a struct to flash with the fds module. This struct conaints 16 bytes, so 4 words. If I'm right the watchdog event handler takes 2*32768khz clock cycles, so around 61uS. I read somehwere that 1 words takes about 46 us. Is there a way to increase this timeout somehow? I need to write all this data to flash before a watchdog timeout occurs.

[Einar Thorsrud]

Hi,

It is not possible to extend the time it takes between the event handler is called and the reset occurs. The only way around this is to sore data in RAM and not in flash, and then (if still needed) write it to flash after the reset. That may seem odd, as the reset behavior table states that the RAM is reset by a watchdog reset. However, the RAM is not explicitly reset and the content will in most cases be intact. You should add a checksum to the data though, so that you can verify after reset that the data is still valid.

[Gueston]

I tried to read out a struct member after a watchdog timeout, but then it's reset to 0. Because I think it get's 0'ed because it re-initializes all the content after a boot. Making a static variable inside a function also didnt help

[Gueston]

It's the app_template what I use for it. I've send it via PM to you to check it.

In my own project I indeed have a bootloader, which makes it more complex. That's why I first want to get it working with the app_template.

[Einar Thorsrud]

Hi,

Ah, that's odd. I see the same. It seems you can fix it by adding keep="Yes" in flash_placement.xml, so that the non_init line looks like this:

    <ProgramSection alignment="4" keep="Yes" load="No" name=".non_init" />

I am note sure why this is, though.

By the way, you can also upload files here using Insert -> Image/video/file, so no need to use other file sharing sites and/or sends in PMs.

[Gueston]

Hi,

I did as you said,  but it's still not working for me. I use nRF52-DK for what it matters.

Can you send me your whole project file so I can try it? Perhaps there is something else missing

By the way, files are limited to 10MB to send here, thats why I used a 3th party service

[Einar Thorsrud]

Hm, I also teste don a nRF52 DK. Here is my changes to your project: ble_app_template_277077.zip.

Regarding size there should not be a 10 MB limitation, but you can anyway get an example project down to fraction of an MB by removing the build folder(s) and prebuilt hex files.

[Gueston]

Now it's getting really odd, also with your files it's not working for me. Just to double check, you press button 3 on the devkit, see the value go +1, then press the reset button and when you press button 3 again you see the value before the reset with a +1?

If so, I'm more thinking of a linker issue or something. Which linker version you use? I have:

GNU ld (GNU Binutils) 2.34.0.20200428

Can you send me your hex file? I'll include mine, just to verify nothing else is going on.1067.ble_app_template_pca10040_s132.hex

[Einar Thorsrud]

Hi,

I tested your hex file, and it works for me. See log:

<info> app_timer: RTC: initialized.
<info> app: Template example started.
<info> app: Fast advertising.
<info> app: Data from previous run:
<info> app:  D8 9D 1A 61 CE 31 BC 7B|...a.1.{
<info> app:  29 39 00 06 B3 4D B3 C6|)9...M..
<info> app: Updated data:
<info> app:  D9 9D 1A 61 CE 31 BC 7B|...a.1.{
<info> app:  29 39 00 06 B3 4D B3 C6|)9...M..
<info> app_timer: RTC: initialized.
<info> app: Template example started.
<info> app: Fast advertising.
<info> app: Data from previous run:
<info> app:  D9 9D 1A 61 CE 31 BC 7B|...a.1.{
<info> app:  29 39 00 06 B3 4D B3 C6|)9...M..
<info> app: Updated data:
<info> app:  DA 9D 1A 61 CE 31 BC 7B|...a.1.{
<info> app:  29 39 00 06 B3 4D B3 C6|)9...M..
<info> app_timer: RTC: initialized.
<info> app: Template example started.
<info> app: Fast advertising.
<info> app: Data from previous run:
<info> app:  DA 9D 1A 61 CE 31 BC 7B|...a.1.{
<info> app:  29 39 00 06 B3 4D B3 C6|)9...M..
<info> app: Updated data:
<info> app:  DB 9D 1A 61 CE 31 BC 7B|...a.1.{
<info> app:  29 39 00 06 B3 4D B3 C6|)9...M..
<info> app_timer: RTC: initialized.
<info> app: Template example started.
<info> app: Fast advertising.
<info> app: Data from previous run:
<info> app:  DB 9D 1A 61 CE 31 BC 7B|...a.1.{
<info> app:  29 39 00 06 B3 4D B3 C6|)9...M..
<info> app: Updated data:
<info> app:  DC 9D 1A 61 CE 31 BC 7B|...a.1.{
<info> app:  29 39 00 06 B3 4D B3 C6|)9...M..

Perhaps the problem here is with how you reset? As mentioned, this is relying on undefined behavior and the type of reset will affect how this happens. I tested using "nrfjprog --reset", which performs a soft reset. If you for instance use a pin reset, things will be different. A watchdog reset should be similar to a soft reset in this regard. But please remember that in addition to types of reset varying there can also be variations between individual ICs etc (again, this is relying on undefined and uncharacterized behaviors).

[Gueston]

Ah, that was the problem. I indeed did a pin reset, because according to this: https://infocenter.nordicsemi.com/index.jsp?topic=%2Fps_nrf52833%2Fpower.html&cp=4_1_0_4_2_5_7&anchor=concept_res_behav

a pin reset has the same behaviour as a wdt reset, so that's why I tested with that one.

I added a watchdog reset to my template program, and there too the RAM retaines after reset. I know you said that this is out of spec, but it seems like wdt reset in this case is same as soft reset not as hard reset.

Anyway, I now try to implement it in my own program, at least I have it working in a template for reference.