Hi everyone,
I need watchdog function on my Mega1280. But it doesn't work: when the reset by watchdog occurs, the bord doesn't restart and the red LED begins to blink, and I have to un-power the board in order to restart it.
I know that the problem is the bootloader: the original bootloader of Mega1280 does'nt support the watchdog reset.
Is there a way to make the watchdog works on Mega1280? For example, a correction in bootloader code or another third part bootloader.
I need the watchdog function, otherwise the controller board is not reliable.
Thanks very much for reading this,and for any help about this.
I had a quick look at the optiboot code - its doesn't special-case the watchdog code for the Mega, perhaps it just has a very old bootloader?
The old bootloader appears to use a WATCHDOG_MODS compile flag for some purpose (and its not set for the 1280, so that might be a culprit?)
Yes it can be corrected.
It is only a couple of lines of C code that need to be inserted in the atmega bootloader code.
(I fixed it for my mega328 AVRs)
There are also a couple of other lines that need to be changed to allow the atmega bootloader code
to compile with the latest gcc tools.
optiboot doesn't work on the 1280/2560 chips.
Do you have a method to burn a new bootloader in your boards?
--- bill
whats the status of this issue?
Anybody got a 1280-bootloader.hex that takes care of the watchdog issue?
The Mega 1280 is sort of backup for my larger Mega 2560 that controls my heating system.
Now I replaced the larger with the smaller one and found out, that the watchdog makes problems.
The sketch with the watchdog compiles and 1280 accepts the code. But when the watchdog resets the 1280, a led begins to blink and the system freezes.
At the 2560 I had to update the bootloader to get it right. Is there some simple way to get the bootloader of the 1280 to work?
You have to update the bootloader on the 1280 to fix the problem as well.
I think the stk500v2 bootloader source compiles and loads on 1280 as well as 2560; that would be the most compatible update. (and the update procedure should be identical as well.)
Optiboot WILL run on a 1280 (but NOT on a 2560; it has a 64kWORD limit to its programming/comm protocols.) However, using optiboot on a 1280 would require a customized boards.txt
I wonder if it might not be a better idea to use an external watchdog timer to control the reset. When Microchip was young (16C57) I had a problem where my code could get caught waiting for missed external input. What I did was to use a pair gate of unused packages from a CD4584 (Hex schmitt trigger inverter) already on the board with an RC on the input which drove a second 4584 gate wired as a half monostable. If the first gate input RC wasn't reset from the controller it's output went high and triggered a half monostable (the second gate to reset the processor.
There are available simpler one package 4 or 5 pin SOTXX scale packages that will do the job much easier today... Perhaps a Tiny13?
Doc
Add hardware... Add another micro-controller....
I'm not a fan at throwing hardware at a software problem.
I'd fix the 1280 bootloader.
--- bill
I'll try to fix the bootloader.
I use the Duemilanove, upload the ISP programmer from examples. When I switch the board to 2560 (connecting the 1280) I get the following error
"avrdude: Expected signature for ATMEGA2560 is 1E 98 01
Double check chip, or use -F to override this check."
I'm sorry for this question: is there a secure and not to difficult way to get the bootloader onto the 1280?
And the answer to my question can be found here:
http://forum.arduino.cc/index.php?topic=100881.msg1382178#msg1382178
I agree Fully with you Bill, adding hardware to fix code issues is rarely wise. However for another run of the autorouter I was able to use 2 unused gates and some jelly bean parts to fix some code that I didn't write..
My point was the obvious old saw about Occam's Razor
Doc