How to add a fallback Hardware watchdog to a device tree/overlay file

[Learner]

Hello,

I am using the task watchdog sample to test the task watchdog subsystem. It is working fine.

I would like to use a hardware watchdog as a fallback; for this I need to define it in the devicetree or an overlay file.

How can I do either of the above?

I am using the following hardware/build environment,

- A proprietary board built around the nRF52833 SoC

- SEGGER Embedded Studio for ARM
  Release 5.60  Build 2021081102.47262
  Nordic Edition
  Windows x64

- Zephyr OS build v2.6.99-ncs1

- SDK 1.7.0

Thank you.

Kind regards

Mohamed

[Learner]

Hi Susheel,

Susheel Nuguru said:

You need to save the data in RAM and not flash if you have to write more than a word in the wdt_callback. This topic is covered and discussed in this thread

I cannot find the file flash_placement.xml where the line containing .non_init is mentioned.

Is there another equivalent file?

Plus, according to Einar Thorsrud,

"(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.)".

Kind regards

Mohamed

[Susheel Nuguru]

Learner said:

I cannot find the file flash_placement.xml where the line containing .non_init is mentioned.

Is there another equivalent file?

There is partition manager and a pm_xxx.yml file which serves similar purpose but it is not the exact same replace of flash_placement.xml.

Learner said:

"(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.)".

Yes, if you see this table and the note below it it says that RAM[n].POWER are retained registers, see Reset behavior. It also says that 

Note: The RAM is never reset, but depending on reset source, RAM content may be corrupted.

In my experience Softreset and rest from whakeup from systemoff should be fine, but other kind of resets might not guarantee the stability of power to RAM block. So hence the disclaimer. Also many start up codes in our SDKs overwrite the RAM.X registers quite early in the startup code, so you should be aware that they might reset the default retention setting.

[Learner]

Hi Susheel,

Susheel Nuguru said:

There is partition manager and a pm_xxx.yml file which serves similar purpose but it is not the exact same replace of flash_placement.xml.

I am afraid it is still not clear what I should be doing to make a section of RAM retainable after a reset.

I may try this as suggested in this thread devzone.nordicsemi.com/.../watchdog-event-handler-timeout,

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

But I am not sure where I can add the keep = "Yes" setting.

An example applicable to my environment (nRF52833, SES SDK v1.7.0) would help.

Kind regards

Mohamed