| Author |
Message |
|
|
 Posted: Jun 20, 2012 - 05:00 PM |
|
Joined: Jun 20, 2012
Posts: 17
|
|
Hi,
I'm currently working on developing a USB bootloader (learning exercise) for my Xmega256 A3U. I'm having some trouble getting started though as writing a bootloader is pretty foreign to me. I'm familiar with C and assembly.
I've looked into AVR Bootloader FAQ, but I'm still unsure about the structure of an AVR bootloader. What types of C and/or assembly files am I developing? The description of initiating a USB device seems too generic. Any help to get me on the right track would be greatly appreciated. Thank you in advance! |
|
|
| |
|
|
|
|
|
|
Posted: Jun 20, 2012 - 05:19 PM |
|
Joined: Jul 18, 2005
Posts: 62361
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
Well there's two parts to this - one is the USB interface that I know nothing about so hopefully Dean or someone can offer advice about that part but once you have a data channel to the PC setup and can deliver bytes into the AVR then the structure of a bootloader is fairly simple. Xmega unlike previous mega/tiny have a fixed, separate area of flash set aside to hold a bootloader so it's no longer a case of trading app space for space to hold the bootloader. After that a bootloader just receives packets of bytes in the SPM pagesize of the device (typically 64/128/256 bytes at a time) and then loads these into a "hidden" buffer inside the AVR and finally another SPM command is issued that says "now write that buffered page of bytes into the main flash array at page/address N". You keep looping receiving pages of bytes and programming them in (after earlier having ensured the page in question was erased) and continue doing this until the sender say you have everything. Then you reboot the chip and it starts executing the new program. You may also have checks in place to make sure everything was programmed OK and don't launch (from the bootloader into the app) if you find something looks amiss.
As to whether you do this in C or Asm is your choice. As the USB stuff (because of its complexity) almost certainly means you will use some kind of library code written in C then I guess it makes sense for the rest of it to be written in C too? What's more, as I say, Xmega have a large, separate area set aside to hold the bootloader so the push that made people choose the slightly more compact Asm solution in the past is no longer really a driving force. |
_________________
|
| |
|
|
|
|
|
|
Posted: Jun 20, 2012 - 05:49 PM |
|
Joined: Jun 20, 2012
Posts: 17
|
|
| clawson - Thank you for your reply. So, if I'm understanding you correctly, after setting up and initializing the USB interface, all the bootloader does is read in the data from the user until the end of the data sequence, reboot the chip, and start program execution? |
|
|
| |
|
|
|
|
|
|
Posted: Jun 20, 2012 - 06:14 PM |
|
Joined: Jul 18, 2005
Posts: 62361
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
| Pretty much - every time it gets N bytes (N = SPM page buffer size) it issues a write_page() on the bytes that have just been fed into the buffer. You may also want to do extra fancy stuff like accepting Intel Hex format and decoding that back to binary but it's not absolutely necessary as you can always hex-2-bin on the PC anyway. |
_________________
|
| |
|
|
|
|
|
|
Posted: Jun 21, 2012 - 03:44 PM |
|
Joined: Jun 20, 2012
Posts: 17
|
|
| On power up, should the bootloader verify that there is an application loaded into flash already? If so, start executing that application. Otherwise, load the bootloader and wait for the user to upload an application? Or should the chip always boot from the bootloader (assuming a USB device is connected to it)? |
|
|
| |
|
|
|
|
|
|
Posted: Jun 21, 2012 - 04:23 PM |
|
Joined: Jul 18, 2005
Posts: 62361
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
| Well the situation is a bit different with USB enable AVRs because you have just one USB cable connection to the PC and usually when you boot up you want to enumerate as whatever the application is using the AVR for (let's say a combined HID and MSD). But when bootloading, at power on you want the thing to start up and enumerate as a CDC (say). So unlike a tiny/mega bootloader where you always set the BOOTRST fuse and the chip always starts in bootloader mode and whether it chooses to use the UARt or not is completely immaterial, it is different with USB enabled chips. You probably don't want the chip to start up as a CDC every time. For this reason the bootloadng strategy of USB chips is a bit different and this also explains the existence of the HWB signal. The idea being that if you want the chip to start in CDC bootloader mode you hold a button and it activates HWB and that affects how the chip boots. So I guess I'm saying that it's not quite so easy to define a perfect strategy for USB-AVR because of the existnece (and need for) the HWB mechanism. |
_________________
|
| |
|
|
|
|
|
|
Posted: Jun 21, 2012 - 05:17 PM |
|
Joined: Jun 20, 2012
Posts: 17
|
|
| Ah, I see. Ok so one HWB mechanism I could implement is a method of grounding a specific pin. If that pin is pulled to ground, the device boots into CDC bootloader mode. Otherwise, the device starts and executes the current application in flash. |
|
|
| |
|
|
|
|
|
|
Posted: Jul 06, 2012 - 11:35 PM |
|
Joined: Jun 20, 2012
Posts: 17
|
|
| I've been making decent progress so far. I was able to finish writing my non-volatile memory driver and I've been working on the USB driver. Something I'm working on is being able to determine when an endpoint setup or transfer ACK has been received. I can't figure out from the Xmega AU manual if an ACK handshake is stored in a data register or if an ACK handshake is sent to a data buffer. |
|
|
| |
|
|
|
|
|
|
Posted: Jul 09, 2012 - 05:16 AM |
|
Joined: Jun 16, 2006
Posts: 617
Location: Sarasota, FL
|
|
| What I understand is that you don't need to worry about the low level stuff on the USB. To send data, you prepare your endpoints, and let the USB module do the transfer when requested by the PC. To receive data, the USB module does the work and notifies you when ready. |
_________________
www.gabotronics.com
|
| |
|
|
|
|
|
|
Posted: Jul 09, 2012 - 03:26 PM |
|
Joined: Jun 20, 2012
Posts: 17
|
|
From Xmega AU manual:
"If data was successfully received, an ACK handshake is returned to the host, and the number of received data bytes, excluding the CRC, is written to the endpoint byte counter (CNT)."
Does this mean that I do not need to worry about accessing or getting the ACK handshake in my driver code? I'm still confused by where/what the host does with this handshake. It would be nice to be able to verify an ACK is received in my driver, or do I really not need to worry about that? |
|
|
| |
|
|
|
|
|
FAQ
Search
Register
Log in to check your private messages
Log in
Maximize
RSS
