Hi,
I have some questions regarding errata 136.
I understand that the workaround is to ignore reset reason bits which are not RESETPIN.
However, I don't understand how ~POWER_RESETREAS_RESETPIN_Msk can help us, as the operation makes pin reset bit 0 and the other bits become 1. Isn't that the opposite from what we want?
In addition, I had some troubles with implementing watchdog, as POWER_RESETREAS_DOG_Msk was always true, until I removed errata 126 fix. Is it possible?
Thanks!
Hi,
However, I don't understand how ~POWER_RESETREAS_RESETPIN_Msk can help us, as the operation makes pin reset bit 0 and the other bits become 1. Isn't that the opposite from what we want?
The RESETREAS register is cleared by writing '1' to the bit, as shown in the PS:
This will ensure that the RESETPIN_Msk is still held when the application checks the specific bit after the errata workaround has executed.
In addition, I had some troubles with implementing watchdog, as POWER_RESETREAS_DOG_Msk was always true, until I removed errata 126 fix. Is it possible?
Are you clearing the RESETREAS by writing '1' to the source bit?
Kind regards,.
Håkon
So the operation if (NRF_POWER->RESETREAS & POWER_RESETREAS_RESETPIN_Msk) checks if the bit is cleared? And if so, it makes that bit 0 and the others cleared (1)?
I'm using sd_power_reset_reason_get to get the bitmap, and then operating & POWER_RESETREAS_DOG_Msk on the reslt, in order to identify watchdog reset. If watchdog was identified, I'm using sd_power_reset_reason_clr(POWER_RESETREAS_DOG_Msk) to clear the bit.
Hi,
Roei said:So the operation if (NRF_POWER->RESETREAS & POWER_RESETREAS_RESETPIN_Msk) checks if the bit is cleared? And if so, it makes that bit 0 and the others cleared (1)?
It checks if the condition has been met.
A read of the register will not alter the contents. Only a write to it will do that.
The errata 136 states that if the reset pin is used, other sources might also be set at the same time. The sequence will ensure that these other resetreas sources are cleared and only the resetpin is set in the register.
Roei said:I'm using sd_power_reset_reason_get to get the bitmap, and then operating & POWER_RESETREAS_DOG_Msk on the reslt, in order to identify watchdog reset. If watchdog was identified, I'm using sd_power_reset_reason_clr(POWER_RESETREAS_DOG_Msk) to clear the bit.
If you see that RESETREAS_DOG_Msk is set in this register, it is likely because the reset reason is due to a watchdog timeout. Try clearing the whole register, as it is accumulative register, meaning it keeps the values. During a debug session, it is quite common to see several reset sources, especially if you are pressing the button from time-to-time, and doing debug-reset from an IDE.
Kind regards,
Håkon
So the operation & with the reset pin mask will actually tell us if the bit is cleared? That's the idea?
And if so - we know that it has been used?
Roei said:So the operation & with the reset pin mask will actually tell us if the bit is cleared?
No, it will clear all other sources if pin reset is set in RESETREAS register. As the errata explains, other bits can be set when RESETREAS_RESETPIN is set.
OK,
So regaring watchdog - your suggestion is to clear whole register bits with 0xFFFFFFFF, in case of watchdog timeout?
OK,
So regaring watchdog - your suggestion is to clear whole register bits with 0xFFFFFFFF, in case of watchdog timeout?
Roei said:So regaring watchdog - your suggestion is to clear whole register bits with 0xFFFFFFFF, in case of watchdog timeout?
You can do this if you plan to not check any other sources.
If you check for other RESETREAS sources; you check the certain bit and clear it (by writing '1' to the source bit position) afterwards.
Kind regards,
Håkon
The problem is as following:
After MCU watchdog, SystemInit() is called and errata 136 workaround is operated.
After that, when my device is turning of, I'm trying to check the restart reason bit, and I can't indicate that the reason is watchdog, because watchdog bit is reset due to errate 136 workaround.
How can I solve that?
I meant when my device is turning on
Hi,
The workaround will only be applied if this is true:
if (NRF_POWER->RESETREAS & POWER_RESETREAS_RESETPIN_Msk){
NRF_POWER->RESETREAS = ~POWER_RESETREAS_RESETPIN_Msk;
}
That should not be true if WDT reset is the only source in RESETREAS. Again, note that this is an accumulate register, meaning that for each reboot, it accumulates and remembers the former reset reason unless the application writes '1' to it.
Kind regards,
Håkon
So how can I know that reset pin will not be set the next time WDT occurs? How can I recognize WDT reset if errata 136 clears the bit?