Electronics > Microcontrollers
AVR Bootloader
James:
An idea that's been sitting in the back of my head for some time now has finally emerged. Firmware updates! I have thought of many ways of doing this, from using another micro to program the master one by SPI or for a recent project using a bootloader on the master chip! The board being worked on has two ATmega164 both connected by UART. One slave the other master. To make it even better the slave is connected to an SD card and also through USB to a computer. With this setup all micros on board can be updated in a flash ( ;)no pun intended!;) ).
I have searched around and found many pre-written bootloaders, such as the list below;
* http://smileymicros.com/blog/2010/10/09/bootloaders/
* http://projects.gbdt.com.au/boot162/
* http://code.google.com/p/avr-ub/
* http://www.scienceprog.com/armega128-bootloader-using-windows-hyper-terminal/
* And some assembly ones at AVR Freaks
However I plan to use the slave micro to communicate (via UART) with the master's bootloader and send it the 'firmware updates' from SD card or the USB interface (both connected to the slave micro). So far, the SD, USB and UART work on the slave micro. The goal now is to burn a bootloader onto the master avr so that when booted into (via interupt on one of the hardware pins) the slave can send data via UART and update the master.
With the background out the way here comes the question! I have searched around for different bootloaders available however they are design to be used with a computer and software written to handle the hex files and structure of packets. What I'm trying to do is understand how blocks from the hex file are sent (with appropriate addresses) and handled by the bootloader so that I can set up my software on the slave micro to find the address and data to be written, then send it via UART to be taken and written to flash by the bootloader of the master micro. My hex files are compiled through AVR Studio and they look as if they are in the intel hex format. If someone could please help my understand what needs to be done I would greatly appreciate it,
Thanks
James
James:
Ok Im going to have a go at writing some code. I'll let you all know how I get on!
One question - Is the 16bit address in an intel hex file the address where the data is to be written to flash?
e.g;
:1000C000C00085FFFCCF9093C600F3CFF894FFCF1C <-- In this case should the data '00C00085FFFCCF9093C600F3CFF894FFCF' be written to flash address '00C0'?
:00000001FF <-- What is this line for? Is it needed for anything?
Thanks
James
Frangible:
You're working with what is known as Intel Hex. Here's a good primer on that:
Wikipedia Article on Intel Hex
It has some links to later stuff - including the 32-bit additions to the original standard.
Here's a basic breakdown:
: 10 00C0 00 C00085FFFCCF9093C600F3CFF894FFCF 1C
Start code = :
Byte Count = 10
Address = 00C0
Record Type = 00
Data = C00085FFFCCF9093C600F3CFF894FFCF
Checksum = 1C
This is a data record, 16 bytes, with a 16-bit offset. Note that if you have received a type 04 record before this one (you may see a type 02, 03 or 05 record if you're working with old Intel processors), you have to add take the 16-bit address in there, left-shift it into the top 16 bits of a 32-bit address and then set the lowest 16 bits to the address provided by this record.
The :00000001FF record is an End Of File record. It means you're done:
: 00 0000 01 FF
Start Code = :
Byte Count = 0
Address = 0000
Record Type = 01
Checksum = FF
cyberfish:
If you already have custom application running on the chip, can't you just write to flash from it? Why have a second chip write it?
Harvs:
I've done something similarish recently. More specifically a bootloader to update Atmega's in a multi-node CAN bus arrangement by having a CAN-USB interface module to plug onto the bus.
Anyhow, you've got a few references there but your missing the most important ones (at a guess by your question, I'm not going to try and read them all.) You need to go get the Atmel application notes on bootloaders. You also need to have a look at the boot.h header file reference for avr-gcc. http://www.nongnu.org/avr-libc/user-manual/group__avr__boot.html, as this is most likely what you'll use to write the bootloader if you write your own.
So hopefully you'll have a look at this and understand how an AVR with bootloader area can write pages to the flash by filling the page buffer, setting a page address pointer then using the store program memory command.
From there, it's all up to you. Yes you could write something to interface with someone else's bootloader, but I recon it's often easier just to write one to do what you need it to do. Also, what I did to make life easier for myself, instead of writing my own code to decode Intel hex format files (which isn't that hard, but I was lazy), I just used hex2bin. This will take your Intel hex format file and produce a pure binary, which is exactly what needs to be written to your flash. Therefore you could just put a .bin file on you SDCARD and basically parse it to the uC being flashed.
Navigation
[0] Message Index
[#] Next page
Go to full version