Replacing the trampoline with a bootloader

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

Hi freaks!

 

I just stumbled over the trampoline_uc3.S and asked myself if it is possible to replace the leading zeros (defined by the trampoline-offset) with a bootloader.

 

#include "trampoline_uc3.h"


//! @{
//! \verbatim


  // This must be linked @ 0x80000000 if it is to be run upon reset.
  .section  .reset, "ax", @progbits


  .global _trampoline
  .type _trampoline, @function
_trampoline:
  // Jump to program start.
  rjmp    program_start

  .org  PROGRAM_START_OFFSET
program_start:
  // Jump to the C runtime startup routine.
  lda.w   pc, _stext


//! \endverbatim
//! @}

My goal is to substitute ".org PROGRAM_START_OFFSET with something like .db 0x34, 0x23, 0x12, .... (single bytes of bootloader-code), to be able to use start a debugging-session on my controller without erasing the bootloader. This method (if it is realizable) would be bullet-proof against accidentially erase of the bootloader.

My problem is that I have no idea (deficit of assembler-knowledge) how t do that.

My hope is that someone could have already done this before and could evenually give me some advise how to achieve this.

 

Greetings,

jabba

Last Edited: Wed. Oct 22, 2014 - 12:14 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In actual fact, the small amount of code in the _trampoline procedure is actually a place-holder for the factory-provided DFU boot-loader itself.

If you are using BATCHISP and the DFU boot-loader to reprogram the chip, the _trampoline code isn't written to the chip, as it would overwrite the boot code in the factory boot-loader already occupying the same space.

 

If you use JTAG to erase and program the chip, the _trampoline procedure is placed at the reset vector to emulate the presence of the boot-loader you just erased.

That way you can develop and debug code that is going to behave the same way it would if it was programmed into the chip using the DFU boot-loader.

 

Using the lightweight _trampoline procedure is quicker and easier then including the binary blob that is the actual DFU boot-loader code.

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

See my topic: https://www.avrfreaks.net/forum/a...

There seems to be something funny going on with the linker if you remove the trampoline completely.

http://proximia.fi - Life Embedded.

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

DukerX wrote:

Using the lightweight _trampoline procedure is quicker and easier then including the binary blob that is the actual DFU boot-loader code.

 

Surely it is easier to fill up that region with zeros, but easy is not enough... :P

(BTW: it is not only the dfu loader i want to store there. i want to replace the trampoline with the standard dfu plus an additional mass-storage-bootloader, which is called right after the dfu-loader.)

I simply want to bypass this whole annoying procedure to:

- merge the 2nd bootlaoder in the firmware

- reflash the original DFU-Loader

- flash the hex via DFU

...

- find a bug, launch via JTAG and start from the beginning :-P

 

Greetings,

jabba

Last Edited: Sun. Oct 26, 2014 - 04:10 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In reality, the space (apart from the rjmp instruction in the _trampoline) is left unchanged from the default erased state of 0xFFFFFFFF. This saves a fixed quantity of time when programming the chip with JTAG.

 

As far as I know, there is no way (in Atmel Studio 6) to enter a debug session without first reprogramming the chip with the current build object, thus erasing any boot-loaders that might reside in the same memory space.

I'm not aware of any tweaks that would trick the build environment to believe the reset vector is anything other then 0x80000000 thus leaving that piece of memory alone.

That doesn't mean they don't exist, but I suspect the only way to get what you describe is to pull in the DFU binary and your custom MSC boot-loader as binary executable blobs located at 0x80000000 and 0x8002000 respectively.

I don't know how to do this either, as I have never tried it myself, but I know this should be possible to do using the standard build tools.