AVR Bootloader - Page 1
Forum section: electronics / general

author: James
author_rank: Newbie
timestamp: July 09, 2011, 06:58:29 am
content: 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 FreaksHowever 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,ThanksJames

author: James
author_rank: Newbie
timestamp: July 09, 2011, 01:15:11 pm
content: 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?ThanksJames

author: Frangible
author_rank: Regular Contributor
timestamp: July 11, 2011, 09:38:53 pm
content: You're working with what is known as Intel Hex. Here's a good primer on that:Wikipedia Article on Intel HexIt has some links to later stuff - including the 32-bit additions to the original standard.Here's a basic breakdown:: 10 00C0 00 C00085FFFCCF9093C600F3CFF894FFCF 1CStart code = :Byte Count = 10Address = 00C0Record Type = 00Data = C00085FFFCCF9093C600F3CFF894FFCFChecksum = 1CThis 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 FFStart Code = :Byte Count = 0Address = 0000Record Type = 01Checksum = FF

author: cyberfish
author_rank: Regular Contributor
timestamp: July 15, 2011, 05:17:00 pm
content: 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?

author: Harvs
author_rank: Super Contributor
timestamp: July 19, 2011, 11:00:40 am
content: 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.

author: James
author_rank: Newbie
timestamp: December 07, 2011, 02:31:15 am
content: Ok, I know its been a while but I have finally written some code for the AVR micros which takes the data sent to it and burns it into the flash memory. Now I'm writing a PC application to send the data from file to the micro through serial. Upon doing this questions have been raised!Looking at a sample of a hex file I have;:101DD000AA1BBB1B51E107C0AA1FBB1FA617B70751:101DE00010F0A61BB70B881F991F5A95A9F780956D:0C1DF0009095BC01CD010895F894FFCF40:101DFC0048656C6C6F2041565220776F726C642171:101E0C00000054686973204C43442075736573203B1. The address now has C on its lower 4 bits. Does this mean that the address has skipped from 1DF0 to 1DFC, jumping some addresses. I am a confused about where the data should be burned to in the micro (which address should be used?). Could I just keep burning the data into flash directly after the 1DF0 address or not?2. Looking at another hex file there is this line;:0400000300003800C1Now I know this is a start segment address record but in terms of programming the micro, what does this line tell me? Do I need to burn it into flash, can I just forget it (i'm guessing not!) or does it provide necessary information for burning the data records to flash?3. One of my hex files starts at the address 3800. Now when programming the micro's flash memory, how do i work out the correct flash address for the 'boot_page_write()' function (from boot.h) so that it writes to the correct area in flash?Then again this may be unecessary as the firmware being programmed into the micro will start from address 0000.This post is quite lengthly but I hope it makes sense! I have never dealt with intel hex files so I am trying to get my head around the whole process of programming a micro from them. Therefore your help is greatly appreciated.Thanks,James

author: JuKu
author_rank: Frequent Contributor
timestamp: December 07, 2011, 06:57:28 am
content: First:http://en.wikipedia.org/wiki/Intel_HEXIf you really need help after that, seehttp://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=111102.The Xmodem to SPI flash routine reads and parses an intel hex file.