xmega serial bootloader

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

Hey!

 

I've been trying to get this working for a few days now with no success.

Currently I'm testing bandtanks bootloader: https://github.com/bandtank/Xmeg...

I have compiled it for xmega32A4U, but when I'm trying to program something over AVR911, I'm getting this error message:

...
Writing | ################################################## | 99% 0.92s ***failed;
...
avrdude: 576 bytes of flash written
avrdude: verifying flash memory against flash.hex:
avrdude: load data flash data from input file flash.hex:
avrdude: input file flash.hex auto detected as Intel Hex
avrdude: input file flash.hex contains 576 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.16s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
         0xff != 0x0c
avrdude: verification error; content mismatch

avrdude done.  Thank you.

The signature reads correctly so I assume the connection is OK (ftdi USB-TTL cable). I can monitor the traffic with logic analyzer aswell.

 

Any ideas or thought where to look to fix the issue?

Or perhaps another bootloader that can easily be ported to 32A4U controller.

 

I have also attached the whole output.

 

-Rain-

 

Attachment(s): 

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

Most of these thread mention "Xboot" at some stage.

 

Having said that I've read good things about bandtank's bootloader too.

 

What do you have in the way of debug capabilities? Do you have a debugger that can do PDI?

 

One thing I'd try at least is to read out the flash contents after the verification failed. Did it really write or not? Was it what's expected (so it's simply the verify that is lying)? If you found it only programmed (for example) 128 bytes out of every 256 (say) then it might be telling you that the issue was to do with flash page sizes or something. This may not be the actual fault but studying what actually happened inside the AVR may give some clue as to what's going on inside.

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

I have JtagICE3 and a bunch of lab equipment to test.

 

I've read the flash back, and it's all 0xFF until the bootloader section:

:10000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF00

...

...

:107FF000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF91
:108000000C94FE400C9408410C9408410C940841D7

 

 

Regarding XBOOT, I could not get that thing to compile in windows & winAVR and I don't have an access to linux machine at this point.

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

bloody-orc wrote:

Regarding XBOOT, I could not get that thing to compile in windows & winAVR and I don't have an access to linux machine at this point.

 

I'm using xboot in windows (although with cygwin). I wouldn't use the very old winAVR. I'm using newer tools, which came with Atmel Studio, but I'm compiling using my own Makefile outside AS.

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

As I'm not that familiar with makefiles and building stuff outside Studio environment I was unable to convert it to a usable format.  Can you perhaps share the XBoot that you have configured (if it is easy to set up here). I think I have cygwin installed on one of my machines so I could test it. I would really like to not resort to finding a prebuilt hex file that I can't modify in the end.

 

-Rain-

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

I've read the flash back, and it's all 0xFF until the bootloader section:

Ah well if you have an ICE3 you can presumably breakpoint and step through the bootloader code to see where it fails? I'd start with the core NVM/SPM stuff. Find the "write page" routine or whatever it is called and breakpoint on entry then get the PC side to send some code. Does it even hit the breakpoint? If it does then step on from there and see if you can see why it fails.

 

EDIT: looking at the code it seems the core page writing is in sp_driver.s - it will likely call SP_LoadFlashPage followed by SP_WriteApplicationPage

 

EDIT2: actually see line 329 onwards in Xmega_Bootloader.c - that's where i'd be putting breakpoints to catch the 'F' memory type after the routine is called from line 107.

Last Edited: Wed. Jan 28, 2015 - 09:33 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK ran a little debugging test and the program never even enters BlockLoad function (it does BlockRead). Will update on where it will "cough up"

 

EDIT: OK it seems the PC side doesn't send out 'B', which should initialize BlockLoad. So I am I correct to assume, that the problem lies within AvrDude atm?

Last Edited: Wed. Jan 28, 2015 - 10:08 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sounds likely. This may be something you can change/fix in the avrdude.conf file.

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

I thought I downloaded the latest version of the Dude. Any suggestions on what to edit there as I have never done that before?

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

OK Apparently using AVR-OSP II programming tool I was able to program the XMEGA controller.

 

But for me the problem with AVRdude still remains as I would like to use a commandline tool for programming (so it could be integrated in Studio).

Can anyone suggest, what could be "missing" or broken in AVRDude configuration.

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

Epic fail / win

Apparently one has to manually erase the device before writing can occur. Added "-e" option to AVRdude and everything works (Y)

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

Finally stopped lurking and joined to say thanks bloody-orc. That "-e" probably saved me a good few hours of faffing.