 |
| Author |
Message |
|
|
 Posted: Aug 14, 2012 - 06:29 AM |
|
Joined: Aug 14, 2012
Posts: 1
|
|
So, I've been playing around with Atmel's CAN bootloader for the AT90CAN128. I've run into a similar issue as this fellow: http://www.avrfreaks.net/index.php?name ... mp;t=70960
Basically, I have a python script and a USB/CAN interface that I am using to upload my firmware. In general, the whole system works great. Except that at the end of the firmware upload, I issue a "start application" message…but nothing happens. Hitting the reset button on my board works: app starts right up, no problem. But using either variant of the Start Application message yields nothing, nothing at all.
Here, for reference, is the message I am sending (in GridConnect format). The first is the "hard reset" message, which triggers the WDT to do a reset:
:S004N0300;
The second is a "jump to" message which causes a jump to the address in the last two bytes
:S004N03010000;
I've checked and double checked against the various App Notes and the code itself, and I cannot for the life of me figure out why it doesn't reset. The thing is, once the code is in there, the routines at the beginning of the bootloader that check for various hardware conditions jump to the application just fine. I'm stumped.
Don |
|
|
| |
|
|
|
|
|
|
Posted: Aug 14, 2012 - 12:24 PM |
|
Joined: Jul 18, 2005
Posts: 62299
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
|
Quote:
But using either variant of the Start Application message yields nothing, nothing at all.
You are going to have to show the code that actually implements that command. For one have you got an LED or something you can use simply to show that the B/L has read and understood the command in the first place? If so then how do you attempt to restart is it just a JMP 0 or a call through a 0'd function pointer or something. But in what state is any hardware the B/L may have been using left? The best strategy of all in a B/L is to force a watchdog reset when ready to enter the app as it puts all the hardware (live interrupts and so on) back to their default, non active state. The startup code of the B/L then inspects the MCUSR register and if the WDRF is set (saying it was a WD reset that just occurred) then the code does the JMP 0 which enters the app with all the h/w back to power-on state.
If you don't do the WD thing then if you have been using interrupts in the B/L do you set IVSEL back for example? |
_________________
|
| |
|
|
|
|
|
|
|
FAQ
Search
Register
Log in to check your private messages
Log in
Maximize
RSS
