[SOLVED] avr-ld guru question: linking ATtiny85 bootloader code into bootloader upgrade program

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

Hello,

 

I want to build a program for ATtiny85 that consists of a C source (upgrade.c) and the content of an intel hex file (bootloader.hex). The C code shall use the ihex code as data and copy it into the upper address space of the ATtiny85 (above 0x1800). The 1st (working) approach is to create a C code data file that will be included into the C source.

const uint16_t bootloader_data[798] PROGMEM = {
0xc017, 0x7a19, 0x0540, 0x0b93, 0x0209, ...
..., 0xba15, 0xcce1, 0xcfff
};

uint16_t bootloader_address = 6528;

I'm now (just out of curiosity) looking for a solution to build a bootloader_linkable.o and link it together with upgrade.o creating a upgrade.hex that can be loaded into the ATtiny.

avr-objcopy -O binary bootloader.bin bootloader.raw
avr-objcopy -I binary -O elf32-avr \
    --rename-section .data=.text \
    --redefine-sym _binary_main_raw_start=bootloader_data \
    --redefine-sym _binary_main_raw_end=bootloader_end \
    bootloader.raw bootloader_linkable.o

This works - but - if I link both parts together 

avr-ld -o upgrade.elf upgrade.o bootloader_linkable.o

I get an elf file where the bootloader part starts at address 0x0000 and the content of upgrade.c with main() beyond the data part - not what I want.

What's wrong with this solution?

 

Rationale:

I'm trying to build a program to upgrade the ATtiny85 micronucleus bootloader in place (https://github.com/micronucleus/micronucleus). This bootloader resides in the upper address space e.g. 0x1800 upwards and is called at reset. It communicates via USB with the PC and loads application programs into lower address space. If during 6 seconds after reset no PC communication starts the bootloader will execute the application. It is possible to upgrade the bootloader in place with an application program that includes the new bootloader code (as data in PROGMEM). The upgrade program erases the old loader and copies the new loader data in place. This program is available, it uses the the approach to include the hex as data. This include file is created by a ruby script - to reduce the program dependencies for the user (most windows user don't have ruby installed) I would like to do it completely with the gcc avr toolchain.

 

Thank you for pushing me in the right direction :)

 

Ciao, Martin

This topic has a solution.
Last Edited: Tue. Sep 5, 2017 - 09:06 AM
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For one thing don't invoke avr-ld directly. Always use the compiler driver when linking. When you do invoke avr-gcc make sure you ALWAYS pass the right -mmcu= value to it. 

 

As to the question, the user manual explains the process:

 

http://www.nongnu.org/avr-libc/u...

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

Hi clawson,

 

Your hint to use avr-gcc instead of avr-ld directly was the solution - it works now as intended :)

I know the FAQ you linked - lot of useful stuff - it produced the *.o file I wanted but the linking failed until I followed your advice - thx a lot!

 

Ciao, Martin