| Author |
Message |
|
|
 Posted: May 10, 2010 - 12:59 AM |
|
Joined: Apr 01, 2010
Posts: 68
Location: San Diego, CA
|
|
I just released a rewritten version of the Atmel bootloader from app note AVR1605. It's a modular bootloader targeted at the AVR XMEGA series with support for multiple serial busses and it should be compatible with all of the XMEGA chips, though at the moment I only have a 64a3 chip to test it with.
XBoot is compiled with avr-gcc and a makefile, so it can easily be compiled on Linux. If somebody out there wants to test it on a Windows box, I would be much obliged.
XBoot is compatible with the AVR109 spec (with a couple of extensions for accessing the signature rows, requires either a custom program or a patched avrdude). You can use avrdude to communicate with it, running at 19200 baud out of the box.
The idea behind XBoot is that it is modular and reconfigurable. You'll need to edit xboot.h for your application, but it's really straightforward.
You can download it from here: http://code.google.com/p/avr-xboot/
Enjoy!
Alex Forencich |
|
|
| |
|
|
|
|
|
|
Posted: May 10, 2010 - 08:54 AM |
|
Joined: Mar 31, 2006
Posts: 48
Location: Corvallis, Oregon
|
|
Hi Alex,
Continuing our discussion from http://survey.avrfreaks.net/index.php?n ... db5d8af6a1 .
After merging your mods, I came up with the same results. Not hitting the interrupt so it wakes up can come from the following reasons:
- It's not getting the boot code in the right spot.
- The boot interrupt vectors aren't enabled.
- The code isn't linked properly.
Yes, I hit all three of these last night ... here we go again  .
The code I had modified from the forum actually copies over, so the interrupts are working on it. My problem with it is the flash is still blank after the bootloader finishes receiving the new program.
I'll keep playing between the two versions I've got. Let me know if you think of anything. |
_________________
_________________
Brad Nelson
http://bradsprojects.wordpress.com
|
| |
|
|
|
|
|
|
Posted: May 10, 2010 - 08:55 AM |
|
Joined: Mar 31, 2006
Posts: 48
Location: Corvallis, Oregon
|
|
| FAIIK, the discussion above is related to testing this bootloader on an XMega256A3 chip, silicon RevB. |
_________________
_________________
Brad Nelson
http://bradsprojects.wordpress.com
|
| |
|
|
|
|
|
|
Posted: May 10, 2010 - 09:09 AM |
|
Joined: Apr 01, 2010
Posts: 68
Location: San Diego, CA
|
|
| Well, all my mods were to the EEPROM controller. I'm working on getting the Flash portion working now. I will let you know when I get something up and running. Right now, it's getting stuck somewhere when it tries to write. It does erase, though. |
_________________
Alex Forencich
XBoot eXtensible Bootloader for AVR ATMEGA and XMEGA
|
| |
|
|
|
|
|
|
Posted: May 10, 2010 - 09:18 AM |
|
Joined: Mar 31, 2006
Posts: 48
Location: Corvallis, Oregon
|
|
Works!
I was going back through your earlier post and saw some things I missed. Following your advice, I let your Makefile program it. It did it even without patching AVRDude (I got stuck with compilation errors, and at this time of night ....).
So it must have been that I've been programming the boot section wrong this whole time ... odd that I still got the responses I did from the bootloader.
Hopefully you haven't hacked your code completely to pieces adding in AVR1008 ...
Thanks for your help, and writing this great bootloader! I'm sure I'll have more questions for you later, and may have a few things to contribute if you're interested. |
_________________
_________________
Brad Nelson
http://bradsprojects.wordpress.com
|
| |
|
|
|
|
|
|
Posted: May 10, 2010 - 09:27 AM |
|
Joined: Apr 01, 2010
Posts: 68
Location: San Diego, CA
|
|
Wow, nice! I'm assuming you used the original unmodified code w/o any AVR1008 additions? It does seem rather strange that it hasn't been programming it properly. Perhaps there was an odd offset in your .bin file? I dunno.
And yeah, I kinda have hacked it to pieces, but I have it in subversion on Google Code, so I can go back to what it was before, no problem.
And what did you change in xboot.c, might I ask?
I would definitely be interested in contributions, if you have any good ideas. The main idea behind this bootloader was that you could use it over the standarad serial port or via I2C when there are a whole bunch (8+) devices on a shared bus. I haven't gotten the boards to test the complete implementation on the shared bus yet, but I did test the address autonegotiation code with an arduino as the master and I think I got all the bugs worked out of that. Logic analyzers are nice
So yeah, if you have an idea for another module or something, fire away. |
_________________
Alex Forencich
XBoot eXtensible Bootloader for AVR ATMEGA and XMEGA
|
| |
|
|
|
|
|
|
Posted: May 10, 2010 - 09:53 AM |
|
Joined: Mar 31, 2006
Posts: 48
Location: Corvallis, Oregon
|
|
Hmm, come to think of it, the current set of files do have the EEPROM change you made. So it might have been a combination of events that got it working correctly. Attached is what I've got right now.
The highlights of the configuration are:
- XMega256A3
- USARTC0
- Baud = 38400
- LED = PortR.1
Compiled code size came out to be 3388 bytes, well within the 8KB XM256 boot size.
I've definitely wanted an I2C bootloader just as you're describing in the past. I had four Mega8's acting as 3 phase BLDC motor controllers on a quadrotor helicopter, and updating the firmware on those meant tearing the whole thing apart ...
I'll let you know if I come across a use case that would be useful that I'd like to add. Seems like I had one, but that was before my memory went to bed... I'll definitely post a "quick start" on my blog, I'll link here once I write it up. |
|
|
| |
|
|
|
|
|
|
Posted: May 10, 2010 - 06:31 PM |
|
Joined: Mar 31, 2006
Posts: 48
Location: Corvallis, Oregon
|
|
Hi Alex,
Here's a little fix I'd recommend. When using the USE_ENTER_UART method, I can't get it to program after the first time the bootloader is loaded. It needs a little timeout so that I have time between resetting/powering on the MCU and hitting enter on the AVRdude command.
The following code works great, it should just need some magic numbers changed to #defines. It gives me a 1 second period to hit the button. This is at around line 209 on my copy of xboot.c:
Code:
#ifdef USE_ENTER_UART
// Check for received character
#ifdef __AVR_XMEGA__
uint8_t retries;
for (retries=5 ; retries>0 ; retries--)
{
if (UART_DEVICE.STATUS & USART_RXCIF_bm)
{
in_bootloader = 1;
comm_mode = MODE_UART;
}
#ifdef USE_LED
LED_PORT.OUTTGL = (1<<LED_PIN);
#endif
_delay_ms(100);
#ifdef USE_LED
LED_PORT.OUTTGL = (1<<LED_PIN);
#endif
_delay_ms(100);
}
#endif // __AVR_XMEGA__
#endif // USE_ENTER_UART
|
|
|
| |
|
|
|
|
|
|
Posted: May 10, 2010 - 07:55 PM |
|
Joined: Mar 31, 2006
Posts: 48
Location: Corvallis, Oregon
|
|
Well, maybe I celebrated a bit early ... I saw the LED blink at the right rate, and thought I had it. I started up minicom to look at the serial data, and it's all garbled. If I send the same program via the AVRISP mkII, it works fine. If I use the bootloader, it seems like the clock is working fine, the code is executing, but something is causing the serial routines to mess up...
I'm guessing either the code isn't being copied properly, or it has to do with interrupts. I'll be investigating...
EDIT: Wow, found that quick ... The 2X bit on the UART is enabled in bootloader, but my application assumed it was clear for the method it took to get 38400 baud. So it was just the baud rate that was screwed up. I don't know if it's worth fixing it the bootloader to protect against crappy code, but assuming coders will write proper code is also a stretch ... |
Last edited by radbrad on May 10, 2010 - 07:59 PM; edited 1 time in total
|
| |
|
|
|
|
|
|
Posted: May 10, 2010 - 07:57 PM |
|
Joined: Apr 01, 2010
Posts: 68
Location: San Diego, CA
|
|
Did you uncomment USE_ENTER_DELAY? That functionality is already built in...
Edit: Although, maybe it should be renamed. Did you look at the README?
Edit x2: And for your code to work properly, all you need to do is add a break. You only check for a received byte every 200ms, so that might not be so good. |
|
|
| |
|
|
|
|
|
|
Posted: May 10, 2010 - 08:01 PM |
|
Joined: Mar 31, 2006
Posts: 48
Location: Corvallis, Oregon
|
|
Good to know, I didn't see that one when editing things. Or maybe I did and thought it was for a different function, either way I'll change it back and give it a shot.
I did use the README as I modified things, guess I didn't look close enough. |
_________________
_________________
Brad Nelson
http://bradsprojects.wordpress.com
|
| |
|
|
|
|
|
|
Posted: May 10, 2010 - 08:10 PM |
|
Joined: Apr 01, 2010
Posts: 68
Location: San Diego, CA
|
|
Yeah, I think you had it commented out in your copy of xboot.h. I kinda thought that was odd since the only other selected entry method was the UART.
That feature was like the first thing I wrote in the bootloader, too. Ah, well. Hopefully it will work on your chip properly. |
_________________
Alex Forencich
XBoot eXtensible Bootloader for AVR ATMEGA and XMEGA
|
| |
|
|
|
|
|
|
Posted: May 10, 2010 - 09:30 PM |
|
Joined: Apr 01, 2010
Posts: 68
Location: San Diego, CA
|
|
|
|
|
|
|
|
Posted: May 11, 2010 - 03:27 AM |
|
Joined: Mar 31, 2006
Posts: 48
Location: Corvallis, Oregon
|
|
Ah, looking back I realize what happened ... I thought the USE_ENTER_* options were mutually exclusive. My bad. Removed my silliness, enabled ENTER_USE_DELAY and recompiled.
It works, but it's still fidgety when programming. My main program uses the same UART as the bootloader and transmits a lot. It's causing AVRDude and XBoot have issues getting in sync with each other. Usually, it takes a few power cycling attempts to get it to erase. Once it erases, it usually fails during the first round of reading/writing. Once it's erased, there's no main program interfering, and the bootloader loads fine on the next power cycle.
This may be a fringe use case considering my UART usage, but if I find a useful change that helps this I'll let you know. It could very well be more easily cured on the AVRDude side, like maybe it's not flushing the serial buffer before getting started. |
_________________
_________________
Brad Nelson
http://bradsprojects.wordpress.com
|
| |
|
|
|
|
|
|
Posted: May 11, 2010 - 04:10 AM |
|
Joined: Mar 31, 2006
Posts: 48
Location: Corvallis, Oregon
|
|
Here's my solution (probably better than any other hacking that could be done elsewhere).
Since my main program is transmitting in ASCII on the shared UART, it can listen for the escape character (0x1B) that AVRDude transmits when it first attempts to contact Starfleet. When the main program receives 0x1B, it causes a software reset:
Code:
if (rx_byte == 0x1B) {
CCPWrite( &RST.CTRL, RST_SWRST_bm );
}
Which hands AVRDude over to the bootloader. Works like a charm. |
|
|
| |
|
|
|
|
|
|
Posted: May 11, 2010 - 04:11 AM |
|
Joined: Apr 01, 2010
Posts: 68
Location: San Diego, CA
|
|
| Hm. What baud rate are you using? It might be a problem with the baud rate selection and clock jitter. Did you uncomment the USE_DFLL line near the top? Also try changing F_CPU in the makefile to 32MHz (32000000). That eliminates the need for the fractional clock generation. And maybe my baud rate generator settings aren't as "golden" as I thought they were. |
_________________
Alex Forencich
XBoot eXtensible Bootloader for AVR ATMEGA and XMEGA
|
| |
|
|
|
|
|
|
Posted: May 11, 2010 - 04:15 AM |
|
Joined: Apr 01, 2010
Posts: 68
Location: San Diego, CA
|
|
|
|
|
|
|
|
Posted: May 11, 2010 - 04:22 AM |
|
Joined: Mar 31, 2006
Posts: 48
Location: Corvallis, Oregon
|
|
Ye olde posting duel ...
I've had a few mid-programming failures on attempts that should have worked, those could possibly be chalked up to baud error. Did you calculate those by hand? Chip45 has a pretty handy (and accurate, I compared several calculations by hand) baud rate calculator spreadsheet. Unlike the one offered by Atmel in their app note, this one opens up and works nicely in OpenOffice as well as Excel (important for Linux junkies like me .
http://www.chip45.com/download/ATxmega_ ... .0.xls.zip
Edit: BTW, the CCPWrite function came from AVR1003, the system clock app note. It does CCP writes in assembly, the way they should be done. |
|
|
| |
|
|
|
|
|
|
Posted: May 11, 2010 - 04:28 AM |
|
Joined: Apr 01, 2010
Posts: 68
Location: San Diego, CA
|
|
I calculated them with a spreadsheet, but it's possible i did it wrong. I hooked up a DSO and played with it until the computer's bit width matched up with the XMega's at the specified BAUD rates. My spreadsheet calculated the ones without fractional scaling fine, so perhaps I just made a little mistake when it factors in BSCALE. What baud rate were you using again? Perhaps I will have to take yet another look at those...
And I suppose that would be linux junkies like us, since I run Ubuntu on most of my computers. (I have a couple with FreeBSD, but those are special cases) |
_________________
Alex Forencich
XBoot eXtensible Bootloader for AVR ATMEGA and XMEGA
|
| |
|
|
|
|
|
|
Posted: May 11, 2010 - 04:33 AM |
|
Joined: Mar 31, 2006
Posts: 48
Location: Corvallis, Oregon
|
|
|
|
|
|
|
FAQ
Search
Register
Log in to check your private messages
Log in
Maximize
RSS
