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

[Einar Thorsrud]

Hi,

That is toolchain dependent. If you use a SES you can do something like this to make a retained buffer:

#define RETAINED_BUFFER_SIZE 16
static int8_t m_retained_buffer[RETAINED_BUFFER_SIZE] __attribute__ ((section(".non_init")));

You can test this by for instance printing the array, incrementing byte 0 and printing again:

    // Print old data
    NRF_LOG_INFO("Data from previoius run:");
    NRF_LOG_HEXDUMP_INFO(m_retained_buffer, sizeof(m_retained_buffer));

    // Update data
    m_retained_buffer[0]++;

    // Print new data
    NRF_LOG_INFO("Updated data:");
    NRF_LOG_HEXDUMP_INFO(m_retained_buffer, sizeof(m_retained_buffer));

[Gueston]

I use the GCC toolchain with makefiles and linkerscript provided by Nordic.

There such a section doesn't exist, but I tried to make one but doesn't retain memory.

Therefore I tried this in SES, and there I can see that byte0 of the retained_buffer increases, but after a reset it gets a certain value, which implies it didn't initialize to 0. However, it doesn't contain the value it had before reset, so it's not retaining its RAM. Am I doing something wrong?

And what would be the correct way to do it in GCC ?

[Einar Thorsrud]

Hi,

It is possible with GCC as well, for instance as discussed in this thread.

Regarding SES it should normally work as long as the example project you use has ".non_init" in the flash_placement.xml file. Did you get a warning during building? (Also, the degree of which RAM content persists may depend on several other factors as well, and this is using the IC out of specification, so you can never be guaranteed that RAM data is retained after a reset.)

[Gueston]

I use the app_template as a test for this. In the flash_placement.xml I can see a ".non-init" section.

I added the code exactly as you described, and I tested as follows:

On button 1 press, it add's 1 to the [0] of the retained buffer. I put this information in a log. See log below:

00> <info> app_timer: RTC: initialized.
00> 
00> <info> app: Template example started.
00> 
00> <info> app: Fast advertising.
00> 
00> <info> app: Data from previoius run:
00> 
00> <info> app:  CA 0B 26 ED 61 FE 0B F9|..&.a...
00> 
00> <info> app:  70 18 F6 89 BD FF 7D 9B|p.....}.
00> 
00> <info> app: Updated data:
00> 
00> <info> app:  CB 0B 26 ED 61 FE 0B F9|..&.a...
00> 
00> <info> app:  70 18 F6 89 BD FF 7D 9B|p.....}.
00> 
00> <info> app: Data from previoius run:
00> 
00> <info> app:  CB 0B 26 ED 61 FE 0B F9|..&.a...
00> 
00> <info> app:  70 18 F6 89 BD FF 7D 9B|p.....}.
00> 
00> <info> app: Updated data:
00> 
00> <info> app:  CC 0B 26 ED 61 FE 0B F9|..&.a...
00> 
00> <info> app:  70 18 F6 89 BD FF 7D 9B|p.....}.
00> 
00> <info> app_timer: RTC: initialized.
00> 
00> <info> app: Template example started.
00> 
00> <info> app: Fast advertising.
00> 
00> <info> app: Data from previoius run:
00> 
00> <info> app:  C8 0B 06 ED 61 FE 0B D9|....a...
00> 
00> <info> app:  70 08 D6 89 BD 7F 7D 93|p.....}.
00> 
00> <info> app: Updated data:
00> 
00> <info> app:  C9 0B 06 ED 61 FE 0B D9|....a...
00> 
00> <info> app:  70 08 D6 89 BD 7F 7D 93|p.....}.
00> 
00> <info> app: Data from previoius run:
00> 
00> <info> app:  C9 0B 06 ED 61 FE 0B D9|....a...
00> 
00> <info> app:  70 08 D6 89 BD 7F 7D 93|p.....}.
00> 
00> <info> app: Updated data:
00> 
00> <info> app:  CA 0B 06 ED 61 FE 0B D9|....a...
00> 
00> <info> app:  70 08 D6 89 BD 7F 7D 93|p.....}.
00> 
00> <info> app_timer: RTC: initialized.
00> 
00> <info> app: Template example started.
00> 
00> <info> app: Fast advertising.
00> 
00> <info> app: Data from previoius run:
00> 
00> <info> app:  C8 03 26 ED 61 FE 0B F9|..&.a...
00> 
00> <info> app:  68 08 D6 C9 AD 7F 7D 9B|h.....}.
00> 
00> <info> app: Updated data:
00> 
00> <info> app:  C9 03 26 ED 61 FE 0B F9|..&.a...
00> 
00> <info> app:  68 08 D6 C9 AD 7F 7D 9B|h.....}.
00> 

So when flashed m_retained_buffer[0] is CA. After a press it get's CB after another press CC. Then I press the reset button on my devkit and then m_retained_buffer[0] becomes suddenly C8. After a couple presses and another reset it becomes C8 again.

[Einar Thorsrud]

Hi,

The data could be corrupted from time to time, but it is a bit odd that it happens so often, and even more odd that it seems to always be reset to 0xC8 when it does. Can you share the full project you tested with? Do you by any chance have anything else that could be suing the same RAM at some point, for instance a bootloader?

[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