How to modify a T85 reset instruction in the .hex file at compile time

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

Hello folks,

 

I'm finishing an I2C bootloader for ATtiny85 written in C. What I'm missing is that when I compile it, the reset vector points to the bootloader address (located on the top of the flash).

 

So far, I have been doing it by hand by modifying the generated .hex file to add the rjmp instruction that points to the bootloader in the address 0. I was thinking about having a small asm code portion with the rjmp instruction that compiles with the bootloader, only to be part of the .hex, but not part of the bootloader itself. The address of the bootloader is set by a variable in the Makefile, so the asm source should also be able to take it from there.

 

The problem is that I do not know how to do what I describe ...

Below is the asm chunk I'm using and the .hex line that I'm cutting & pasting into the beginning of the bootloader's .hex. The "BOOTLOADER_ADDRESS" should come from the Makefile, this I don't know how to do it either.

 

Thank you in advance for your help.

 

;
#define BOOTLOADER_ADDRESS 0x1980

.CSEG
.ORG 0x0							/* Reset vector, it is modified to jump to the bootloader after POR */
	reset:
			rjmp bootloader

.ORG (BOOTLOADER_ADDRESS / 2)		/* Bootloader start address = (1980 / 2) */
	bootloader:
			nop
:020000020000FC
:02000000BFCC73
:02198000000065
:00000001FF

 

Last Edited: Fri. Aug 31, 2018 - 01:38 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here's what I did for my bootloader.

 

In the linker settings I create a FLASH segment with:

.appvector=0x0000

Then, In my C code I have this line:

const uint8_t AppVector[4]  __attribute__ ((section (".appvector"))) = { 0x0c , 0x94 , 0x00 , 0x20 };

This is for an XMEGA with 4-byte vectors. For the TINY, you should just need a 2-byte array with 0xBF 0xCC.

 

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

This is not exactly what I've been thinking of, but I'll give it a try ... Thank you.

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

Optiboot's "Virtual Boot partition" just lets the vectors stay 0xFFFF when it's first programmed, and then modifies the reset vectors "on the fly" in any program that it bootloads at location 0.  It's a bit bulkier than ideal, but seems to work...

 

https://github.com/Optiboot/opti...

 

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

This only works for me if I use standard sections (e.g. init0), but it places the array bytes inside the .text area, after 0x1980. Would it be possible that I'm missing some LDFLAGS option to be able to use other section names (e.g. .appvector)?

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

Thanks for your suggestion. I'm doing something similar to preserve the jump to the bootloader.

 

I'm intercepting the application's page 0 before flashing it to read the first two bytes and replace them with the previous values. Besides, I'm using these two bytes to calculate a "trampoline" rjmp to jump back to the app from the bootloader after flashing.

 

The problem I have is that the "previous values" have to be the correct jump instruction to the bootloader before such function runs. I wouldn't want to use more flash with another calculation for a rjmp instruction that it will remain the same after it runs for the first time. The other option it would be to use fixed rjmp values to save memory, but it wouldn't be possible to change the bootloader address without modifying the code, besides the makefile.