Any AVR Bootloader tutorial

Go To Last Post
9 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

i want to know the avr bootloader, so any tutorial regarding this.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Know WHAT about it? Which are good ones? How to write one? How to program one in? How to use one?

If you are just looking for a good one then try the ones written by stevech or danni (Peter):

https://www.avrfreaks.net/index.p...
https://www.avrfreaks.net/index.p...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My vote for a tutorial on the subject would be a) the essential elements to writing one, and examples of such. b) how to interface with the "standard" one. What is it? The Atmel AVR910? Something like that....

-Tony (who has just enough experience with bootloaders to get in trouble)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
My vote for a tutorial on the subject would be...
...just enough experience with bootloaders to get in trouble
Then you are at the perfect place to write such a wonderous tutorial! Nothing like teaching to solidify your learning.

Here's a little on the Butterfly bootloader and the AVR109 app note.

(AVR910 is on ISP; AVR109 is on self programming. Both are relevant)

Chuck Baird

"I wish I were dumber so I could be more certain about my opinions. It looks fun." -- Scott Adams

http://www.cbaird.org

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Also search for a "smallest bootloader" thread on here which was actually a bit of a C vs Asm challenge (Asm won!) but also covered a lot of ground.

But with Steve and Peter's excellent examples I'm not really sure I see much point in reinventing the (perfectly round already) wheel again unless it's just being done as an intellectual exercise to see what SPM is all about? For GCC users the example at:

http://www.gnu.org/savannah-chec...

is actually a pretty good starting point (well it worked for me when I wanted to bolt some SPM onto an app rather than developing a separate bootloader)

EDIT: the "smallest bootloader" thread I was thinking of:

https://www.avrfreaks.net/index.p...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry to bring a very old topic live again. Is there any way to use the bootloader via IP?

Most of the bootloaders are using UART.

cs

I'm happy ytd, today, and tmr :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For one of the Circuit Cellar contests I put together a little Butterfly bootloader that used a WIZnet Ethernet module. Have a look and see if it helps at all.

Chuck Baird

"I wish I were dumber so I could be more certain about my opinions. It looks fun." -- Scott Adams

http://www.cbaird.org

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

zbaird wrote:
For one of the Circuit Cellar contests I put together a little Butterfly bootloader that used a WIZnet Ethernet module. Have a look and see if it helps at all.

Thanks a lot...

One question: What happen if during the transmission the connection cut off? Or it contains invalid codes due to noise...Can I roll back to the previous firmware?

I am thinking to build a reliable IP based bootloader, the new firmware will be download to a EEPROM chip, and another EEPROM chip holds the current code.

A check was done on the new firmware to determine it is valid or not, use CRC?

Then once Reset, the bootloader will load the new firmware from the EEPROM. However, if some errors happen when executing the new firmware (the firmware always has a watchdog timer), the Watchdog timer will reset and the bootloader will load the old firmware back.

The max code size is 64k. Do you think this is practical or reliable method?

cs

I'm happy ytd, today, and tmr :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's been long enough ago that I don't remember what I did, but it was pretty simple minded for the contest. I was just going for a "proof of concept" more than a robust prototype. Whatever I did is in the write-up.

Loading to an EEPROM which is then copied to flash seems reasonable to me, given sufficient checks of validity, etc. Maybe others will give their opinions on this. Will you alternate between the two EEPROMs for revisions (the new one into one EEPROM, the previous one lives in the other)? Or will you have a "base" version in one EEPROM that never gets overwritten and the updates go into the other EEPROM?

Sounds like an interesting project.

Chuck Baird

"I wish I were dumber so I could be more certain about my opinions. It looks fun." -- Scott Adams

http://www.cbaird.org