fast tiny & mega UART bootloader with tiny85 and C app.

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

PLEASE IGNORE MOST OF THIS IS WRONG. See below.
Ifor

I have been fighting this for a couple of days but have managed to get it working so I thought I would share my experiences and see if some stuff I have a bit messy can be sorted out.

Project is using a Tiny85 with C code I wanted a one wire bootloader and this one looks perfect for the job, thanks Danni.

Firstly I had to download the 1.9 version as well as the 2.1 version. The 1.9 version includes a little schematic for the one-wire interface.

The 2.1 bootloader code assembled no trouble just changing it for the tiny85 and my PB0 usage. I had trouble getting the resultant hex file to download with AVRStudio and a dragon or STK500 using ISP. I did not get an obvious error but it all looked very quick and when I read back the flash I just had all ffs. Letting the code assemble to address 0 the generated hex file loaded OK. I finally modified the fastload.inc file just adding in a rjmp to the bootloader e.g.

.list
    rjmp init;
 .org BootStart
...

This put the rjmp into address 0 at the reset vector. This hex file uploaded correctly and I was able to check the connection to my pc with fboot. I do not understand why the original hex file fails to load, without the jump I was just expecting all the ff's which are nops to be executed and hence the bootloader to be entered....

The application code needs to be set-up to call the bootloader on reset and to put an rjmp back to the normal application code in the last two bytes before the bootloader code. In assembler this is straight forward but I have had to read up a lot to get a somewhat off perfect solution for my C code. Here is what I have added.

void init1(void) __attribute__((naked)) __attribute__((section (".init1")));
void init1(void)
{
}

void application(void) __attribute__((naked)) __attribute__((section (".appstart")));
void application(void)
{
    asm ("rjmp init1");
}

void __init(void) __attribute__((naked)) __attribute__((section(".init0")));
void __init()
{
    asm("rjmp 0x1e00");
}

I have added the following to the linker args.
-Wl,--section-start=.appstart=0x1dfe

The empty init1 code in the .init1 section gives me a label I can use with my rjmp the .init1 section is positioned before any of the standard start-up c code.

The application code is just the rjmp that the bootloader will call once it is done the linker directive forces this to the correct place for the tiny85.

The __init() code is my hack for getting into the bootloader. There must be a way to get the reset vector to rjmp to the bootloader directly but I could not work it out. With this set-up it goes to my __init code and that just rjmps into the bootloader. This is far from perfect but it is working.

With my source code with these changes I had what I though would be a good hex file. Unfortunately fboot refuses to load it it complains it is to big. It turns out that the default bootloader code will not let you modify the two bytes before it where the rjmp to the application lives. I assume the assumption is that you can just always jump to the same address but I am not clear how to get a fixed address for my c code as the entry points move. I got around this by modifying fastload.h and removing the -2 from the definition of UserFlash. This variation on the bootloader will now upload my new hex file and everything seams to be working ok.

Last Edited: Thu. Dec 3, 2009 - 10:25 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ifor wrote:
The application code needs to be set-up to call the bootloader on reset and to put an rjmp back to the normal application code in the last two bytes before the bootloader code.

Thats wrong. :!:

The application must be written in the same way, like no bootloader was used.

The only restriction was, that the first instruction must be a RJMP.
Then the bootloader catch this RJMP and do all needed changes on it.

Thus the last word below the bootloader must be reserved, that the bootloader can place the RJMP to the application on it.

Peter

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

Apologies, I clearly miss understood. I just ripped out my messy code and it just works, thinking about it I can see how you can patch up the code fairly easaly given that inital rjmp instruction. I clearly got confused when I had to put the rjmp in to the bootloader.hex file to get that to load... I guess I should just try that again and maybe check for AVRStudio updates or try one of the command line alternatives.

Thanks a lot for the clarification and even more thanks for the great bootloader.

Ifor