Hi
我想当监督核心转储[系统转储]]reset is occurred.
And load the dump data when boot up the system.
Please give any hint or method or example code
Thank you
Device:
⚠️
Hi there.. thanks for coming to the forums. Exciting news! we’re now in the process of moving to our new forum platform that will offer better functionality and is contained within the main Dialog website. All posts and accounts have been migrated. We’re now accepting traffic on the new forum only - please POST any new threads at//www.wsdof.com/support. We’ll be fixing bugs / optimising the searching and tagging over the coming days.
Hi there.. thanks for coming to the forums. Exciting news! we’re now in the process of moving to our new forum platform that will offer better functionality and is contained within the main Dialog website. All posts and accounts have been migrated. We’re now accepting traffic on the new forum only - please POST any new threads at//www.wsdof.com/support. We’ll be fixing bugs / optimising the searching and tagging over the coming days.
Hi jakehan,
When the NMI has occured the SDK will save a snapshot of the 68x registers in a memory location that the system is using only for that purpose (in the case of the NMI the status base is 0x7FC5600), that means that when the system reboots the area will be populated with the register values that caused the NMI for you to read and store or handle however you require. So you are not in development mode and you would like to store the data in the flash for example you can push those data from those specific memory location to the flash.
Thanks MT_dialog
Do you mean, I have to set the registers as below?
WATCHDOG_CTRL_REG.NMI_RST = 0x00
WATCHDOG_CTRL.WDOG_VAL = 0x00
== I found the description [Table 657: Register map WDOG] in DA14681-01_2v3.pdf ===
If WATCHDOG_CTRL_REG[NMI_RST] = 0 then
If WDOG_VAL = 0 -> NMI (Non Maskable Interrupt)
===================================================================
I also found the store code in the project. Is this what you mentioned?
__RETAINED_CODE void hw_watchdog_handle_int(unsigned long *exception_args)
{
:
if (exception_args != NULL) {
*(volatile unsigned long *)(STATUS_BASE ) = exception_args[0]; // R0
*(volatile unsigned long *)(STATUS_BASE + 0x04) = exception_args[1]; // R1
*(volatile unsigned long *)(STATUS_BASE + 0x08) = exception_args[2]; // R2
*(volatile unsigned long *)(STATUS_BASE + 0x0C) = exception_args[3]; // R3
:
*(volatile unsigned long *)(STATUS_BASE + 0x30) = (*((volatile unsigned long *)(0xE000ED3C))); // AFSR
*(volatile unsigned long *)(STATUS_BASE + 0x34) = (*((volatile unsigned long *)(0xE000ED34))); // MMAR
*(volatile unsigned long *)(STATUS_BASE + 0x38) = (*((volatile unsigned long *)(0xE000ED38))); // BFAR
}
}
Hi jakehan,
Yes, this is what i was reffering to, and you dont have to do anything explictly, if you have enabled the watchdog by using the dg_configUSE_WDOG, then when the watchdog issues an interrupt and the NMI executes then the handler that will save the state of the ARM is going to be stored in the STATUS_BASE that i have mentioned.
Thanks MT_dialog
Thank you for your answer.
What I want to implement is seemless boot-up.
After the boot-up I want to re-start the point right before the watchdog reset.
[stack push when watchdog occur, and stack pop after the reset.]
Is it possible?
Hi jakehan,
What you are mentioning might be possible and quite tricky (i am not able to give specific instructions on how to do this since such a scheme is not implemented, also as mentioned is quite tricky since you will have to save besides the ARM registers, the main stack, the stack for each task in order to reapply after reboot and those are a few things that i can think of). But i dont see a reason for something like this. For example lets assume that the device hits the NMI handler since the watchdog occurs, that means that the code is stuck in a speciifc instruction and the system becomes unresponsive (try to access a peripheral and there is no response, etc). The NMI hits and you save the state of the ARM and you assume that the RAM is ok since it hasn't been a power down and upon boot up you reapply the ARM registers, the device is going to continue from the part where it was stuck, and an another NMI will occurs in a few seconds. So, i dont see a reason for implementing something like this, i mean its quite the same if you prevent reset from the NMI due to watchdog and continue executing the code.
Thanks MT_dialog