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]

You need to use some memory that is not initialized by your application when it starts. That means that global and static variables are not usable as they always automatically zero initialized in C. It is better to reserve some part of the memory, and then make a pointer to it and operate on that.

[Gueston]

Do you know how can I do that? Is there some compiler value for this, like  __attribute__((...))

or how can I prevent memory being intialized after starting?

[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.)