XMEGA SD/MMC Bootloader

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

I just wrote a bootloader for a project I'm working on that uses the 128A1. It looks for a intel hex file called "fw.hex" in the root of the memory card. Once it finds one it enters into a loop until pin 0 on PORTA goes low, at which point the programming starts. It takes a little over a minute to program 80K.

Hope this is helpful to someone else.

Attachment(s): 

Last Edited: Fri. Jul 12, 2013 - 11:56 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brilliant, I just took delivery of an Xmega board - think I'll wire it up to an SD/MMC and use this for programming it. Thanks.

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

I struggled several days to get this great bootloader working when using AVR Studio 5 or 5.1. The mmc-code worked well when tested in the application flash area but failed when loaded into the boot section. Finally I found out that there seems to be a problem in AVRToolchain\avr\lib\avrxmega7\crtx128a1.o
When I replaced that with the same file from
WinAVR-20100110\avr\lib\avrxmega7 (from AVR-Studio 4) it worked like a charm. I suspect that the same problem is with the crtx... for other xmega types as well.
Karl

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

I took the liberty to extend/modify your code so that it
1) actually works for flash code beyond 64k
2) optionally enables version and device id control
3) uses checksum error control

The version/id control needs a small edit action on the hex file to be flashed as described in the code, and of course that the version/id information is added to the application program (see code).
If enabled, version control assures that only a higher version than the current application version gets flashed. A blank application section will always be flashed (if the device id's of application and bootloader match). The version/id information is stored in the last 6 flash bytes before the boot section.

The code was tested on an XMega128A1 using a FAT16 micro-SD. I have not tested FAT32. All hardware information that has to be adapted is in config.h

Be careful if you use AVR Studio 5 or 5.1 (see my post above). You are safe using 5 or 5.1 with WINAVR-20100110 (I took that from AVR Studio 4) instead of the built-in Atmel Toolchain.
I hope this extension of your code is useful.
Karl

Attachment(s): 

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

There is a small error in the description of the functionality in ParseHexFile, quoting:
"If version control is on and the hex file does not conform to the above rules, the bootloader will stop and will not start any application code. The flash memory will not be modified in that case. To start the original code, remove the SD and reset the processor or delete the "FW.HEX" file on the SD."

Actually, if the hex file is found but either does not have the correct device ID or does not have a higher version number, the bootloader will start the original code in flash if there is any. You can easily change that to a processor halt (replace the two return arguments of line 250 and 253 with FALSE instead of TRUE). Also, in line 71 and 74 of main.c the #if LED.... #endif should not be commented out as they are now.
My apologies.
Karl

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

I'm sorry if this isn't the right place to ask this.
I've followed the example in ParseHexFile.c and I can't generate an Hex file similar to the one you describe. Is there any other compilator option I'm missing? I'm using the same chip ATxmega 128A1.

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

Just looking at the code in parsehexfile.c this looks awfully suspicious:

		address += offset; //add offset, for strange reasons, jst adding the offset does not work! e.g. 0x10000 is not added right 
		address = address | offset; //needed together with preceeding statement, otherwise offset is not added at all! (???!!! compiler???)

The author seems to be saying it's a workaround to a compiler bug. OTOH I guess it's something to do with types not being used correctly (I don't intend to investigate) but if the compiler is "working right" it's possible these lines may now be generating the wrong result.

Other than that a cursory read through suggests that code should be able to cope with most hex files and variable line lengths etc. Are you able to step it in a debugger and see where it goes wrong with your own .hex files? (as I say I suspect the address (which is bytes 2 and 3) may be interpreted incorrectly).

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

I hadn't look into ParseFile since I wasn't able to generate "correct" .hex files. Now that I have looked into it those 2 lines seem strange indeed.

Also I'm using a large hex (>100k code) and I can't make the bootloader accept it.

I don't have any debugger available right now, if any kind soul does and could look into it i'd be grateful.

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

The offset address code indeed looks suspicious but was the only way that I got it to work with the tools I used. If you are using different tools, it might be important to check this, although I can hardly imagine that the "superfluous" OR statement I had to add can actually hurt if the add statement itself works correctly with a different tool set.

To be honest, in the hex file I took to test the bootloader the only code part above 64K was the version id, which is at the 128k boundary. That was however handled correctly. I am attaching the hex file I used for testing.
Karl

Attachment(s):