-
-
Notifications
You must be signed in to change notification settings - Fork 7k
Nano WDT/ResetButton Failure #6228
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Are you talking about https://github.com/arduino/Arduino/issues/4492? |
No I do not think so. When the program crashed initially I did not have WDT installed. At that point it would not recover with the reset switch. Then I installed WDT (set to 8S) ) which also does not provide a crash recovery. Recovery requires a power re-cycle. It appears to become locked up in a self resetting loop. The P13 stops flashing whilst the reset switch is pressed then resumes immediately when the reset switch is release. Thus it does not seem to be the same situation as #4492 although there may be an indirect relationship. What really seems peculiar here is that there is a difference between reset pin and power cycle reset. This suggests something in volatile memory is not being cleared by the cold boot pin reset. IMHO a pin reset should re-initialize the whole MPU completely equivalent to a power cycle reset. Otherwise the WDT cannot be relied upon. Thanks for your interest! |
The problem seems to be the same as described here: Possibly changing the Nano bootloader to the optiboot code as described in the above link for the Pro Mini would also resolve the problem for the Nano board. Apparently this can be done by changing the Arduino Nano bootloader statements within the boards.txt file. My boards.txt file implies that the avrdude bootloader is currently being used. Possibly this change or a better alternative should be considered for an Arduino distribution update. tma |
That's https://github.com/arduino/Arduino/issues/4492 avrdude is not a bootloader, it's the upload tool. |
Greetings, Thanks to the information linked below and the associated info posted under #4492 I have been able to correct this problem for my Nano board project by replacing the default bootloader with the improved optiboot code as recommended here: I noticed the latest version (1.8.2) of the Arduino IDE still has different default bootloaders specified in the boards .txt file the for the UNO and the NANO. For UNO the IDE uses optiboot as a default but for Nano it uses ATmegaBOOT. Is there a reason for using a different bootloader for NANO (and other boards that use the 32 pin Atmega328) than that used for the UNO? It is my understanding that the UNO is a platform that can be used to develop applications for the NANO board. It would seem logical that both should use the same bootloader by default to help ensure compatibility. Since this issue can apparently impact the reliability of all sketches that run on 32 pin SMD Atmega328 boards, not just the sketches that use the WDT, I wonder if those involved with the Arduino IDE development are aware of the significance here? Since #4492 was raised almost a year and a half ago I wonder if this has been put on the back burner for good reason? tma |
Closing as duplicate of https://github.com/arduino/Arduino/issues/4492. |
Greetings,
I am developing an interrupt driven I/O intensive program using a Nano that crashes after a few days of continuous operation. I have WDT implemented which does not correct the problem nor does pressing the reset button. A power cycle reset is required to get it running again. When it fails the P13 LED flashes quickly and I presume the problem is a loop cycle that is resetting the MPU. As a power cycle reset is needed to get it running again and as the normal reset does not work it is probable that the issue is volatile memory content related.
This is a significant issue as it causes the WDT function to fail making any unattended applications (that could fail do to noise glitches or other reasons) insecure. I wonder if a setmem or equivalent statement is needed in the reset boot code to clear all the volatile memory each time there is a reset. If there is already such a statement it would appear it is failing to do the job under certain conditions.
For my application I am going to install an external WDT that implements a power off/on cycle as it is apparent, in this case at least, that the internal WDT code cannot be relied upon for this unattended application.
tma
The text was updated successfully, but these errors were encountered: