MSC Bootloader without DFU Bootloader?

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

Does anyone successfully implemented the MSC Bootloader and user application without the DFU bootloader?

My MSC bootloader does not activate when my user application calls for it, the controller just reboot.

Best regards
Casper

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

did you adjust the entry point of your boot loader?
you must make sure that it's startup code get's executed.

you may link it to 0x80000000 or use a trampolin to reach it.

-sb

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

Only when programming using avr32program.
I can se in the output.lss that the MSC bootloader code is compiled to start at address 0x80002000, so I need to change that to 0x80000000, but where should I change that?

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

This depends on your startup code...

your linker script should already preset an entry point of 0x80000000 but your startup code may use a PROGRAM_START_OFFSET that you have to define to 0

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

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

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

do you use the trampoline mechanism?
then you should check trampoline_uc3.h for the definition of your offset.

-sb

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

i currently have the same problem.

i've modified the msc's startup code (boot.x), removed the line ".org 0x00002000" according to Atmel's AVR32758 doc.

i assumed this would make the msc bootloader start at 0x80000000?

do i still need to modify something on the trampoline?

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

I assume that you're not using the trampoline any longer.
trampoline_uc3.h exactly defines the PROGRAM_START_OFFSET,
that is now missing in your code ...

Does your startup code looks like mine (I still use the trampoline, since I do use a first level bootloader at 0x80000000)?

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


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

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

The .reset section should define an entry point of 0x80000000
if you're using the standard linker script. So what is your problem now?

-sb

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

hi sam, thanks for the response.

just for reference, i'm using the files from AVR32758 appnote and a EVK1100 devboard.

sambrown wrote:
I assume that you're not using the trampoline any longer.
trampoline_uc3.h exactly defines the PROGRAM_START_OFFSET,
that is now missing in your code ...

the projects (MSC bootloader and the EVK1100 example application) still contain the trampoline.x file when rebuilding. i haven't made any changes to them.
sambrown wrote:
Does your startup code looks like mine (I still use the trampoline, since I do use a first level bootloader at 0x80000000)?

yes, it's the same for both bootloader and application.
sambrown wrote:
The .reset section should define an entry point of 0x80000000
if you're using the standard linker script. So what is your problem now?
-sb

i assumed by removing that line, as suggested by the appnote on page 14, the startup address for the MSC bootloader will now be 0x80000000 instead of 0x80002000?

the problem is when a USB stick is attached, nothing happens. the application software does its job of resetting the micro upon pressing the PB0 button. after that it is stuck. the LED on the USB stick turns on, but that's it.

btw, i used the jtag programming script that came with the appnote. i made some changes to reflect that the dfu bootloader is not used anymore. see attached file.

appreciate any response.

Attachment(s): 

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

Basically you must find out what exactly happens.
I'd advise you to add some printfs to main() -> isp.c
The problem is that you need to configure the usart for that correctly...

Since you have a JTAG debugger it may be better to compile the bootloader
with -O1 and debug it to find out if it really reaches main() and if so
what's going wrong then.

-sb

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

finally, i've found a workaround.

on the boot.x file, there is a section where the ISP version (1 word) is read on startup. this section should exactly be at offset 0x00000004 (whether startup address is at 0x00002000 or not).

by removing the ".org 0x00002000" line, the ISP version would no longer be at that specific offset.

i've confirmed this by looking at the disassembly listing using avr32-objdump.

the solution is simply to move that particular section to the place where the line was removed (before _evba section). see new code below:

  // Reset vector: This must be linked @ 0x80000000.
  .global _start
  .type _start, @function
_start:
  rjmp    _evba

//  dfu bootloader removed
//  msc bootloader now starts at 0x80000000
//  .org  0x00002000

  // ISP version: This word must be at offset 0x00000004 relatively to the ISP
  // start address for all past, present and future versions of the ISP.
  .global isp_version
  .type isp_version, @object
isp_version:
  .word ISP_VERSION

  // Start of exception vector table: Unrecoverable exception.
  .global _evba
  .type _evba, @function
_evba:
  rjmp    handle_unrecoverable_exception