AT32UC3C0512 BootLoader overwritten with 'Trampoline' after 'bootloading' from ELF file. - SOLVED

1 post / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello AvrFreaks!

I have a custom design using the AT32UC3C0512 MCU and am fighting with the bootloader. My design is based on a previous design which was built using a Pre-AS7 IDE (AS6 something) and also the jtagice3 debugger. I am using AS7 with the AtmelICE debugger. The previous design had a C# 'configuration utility' that would interface with the bootloader to perform a 'DFU' among other things. This all worked just fine with the previous design and the tools used. You could keep uploading new (or the same) code over and over again, and it would continue to do it as the bootloader would remain in flash...

 

Now, I'm finding that with the new design and the new tools, the bootloader appears to be overwritten with the 'Trampoline' and so you get to 'Update' once, and then you're done. No more bootloader in existence to upload new code with. I have looked high and low for ways to get around this to no avail. I've tried using the 'Additional modules' functionality in the Advanced section of the projects 'properties' with no help. I've resorted to using batch files with 'atprogram' to get back the bootloader and to program the fuses, bootloader and config bytes, but this requires using the JTAG port and the AtmelICE gizmo.

 

Puh-leeze, someone tell me how to program this thing so that the bootloader remains. My understanding is that this bootloader is supposed to have its own 'trampoline' of sorts and decides whether to jump to the application already in memory or do the 'bootloader' thing based on the config bytes that it reads up there in 'user flash'...

 

(and please, no 'why would you want to do that?' answers...)

 

-WJM

 

Alrighty then - figured out what's going on here... The JTAG connection to the board DOES wipe out the existing bootloader in the devices memory when connected and a the device is programmed through this I/F (via a chip-erase). To get it back, I had to  run the aforementioned batch file that have 'atprogram' commands. The last command in that batch file was "atprogram -xr -t jtagice3 -i jtag -d at32uc3c0512c write -fs -o 0xfffe0018 --values f877ffff". This command failed with an error message that I  managed to miss everytime. It was NOT programming the fuse values. The "-o 0xfffe0018" text sets some sort of offset for the fuses, which I decided wasn't needed since the command "-fs" is telling to program 'THE FUSES'. I deleted this text so that the last command was then simply "atprogram -xr -t atmelice -i jtag -d at32uc3c0512c write -fs --values F877FFFF" and BINGO, it all began to work as advertised...

 

I hope my question and solution offers someone else some help on down the road...

 

-WJM

WJM

Last Edited: Mon. Mar 5, 2018 - 11:09 PM