Bootloader progamming itself. How?

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

Hello.
For my XMega256 application I wrote a simple bootloader to reprogram the application section, it's working as expected and I'm fine with it.
Now I'd like to explore the possiblity for the bootloader to reprogram itself.
I read all the bootloader FAQ and I found this sentence:
"Since the bootloader can't easily update itself and applications almost never modify the
bootloader, you will need an external programmer to write the bootloader to the MCU."
So I assume there is soem hard way to do it, but I read a lot of times the datasheet and I wasn't able to find any indication on how can I achieve my goal.
Any help will be appreciated.
TIA

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

The simple answer is DON'T DO IT.

The complex answer is that you must always run code from a known good sector of flash.

So if you want to re-program the bootloader, you must put some new sector writing code into flash before erasing the your existing bootloader.
Use this temporary sector writing code to install the new bootloader. Once installed, you can transfer control to the new bootloader and erase your temporary code.

In practice, this temporary function can easily find a spare hiding place in the boot section. All the same you do end up wondering which bootstrap you are actually pulling yourself up with.

David.

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

Thanks for your answer.
Unfortunately in my job I can't just go with the simple question, I need to justify it...
If it's not too much trouble, I'd like to expand a little the discussion, maybe just to have more information.

Basically I should have the bootloader splitted in two, the first section can update the second and viceversa, is that right?
And what if I just get the new bootloader copy from the usart, put it in RAM, write a copy of the actual bootloader in application section and then pass the control to it. Then this code could read the RAM and write it to the boot section.
I have two doubt about this solution: the first one is that the application is NRWW. I don't really understand the datasheet on this, it seems to me that I can write the boot section, I just have to deal with the fact that the CPU is halted when I do that. This would not be a problem, I'm using a bugged version of the XMega which has this exact problem when I write the EEPROM, so I can manage that.
The second doubt: if I can't write boot section with code running in the application section it's because the SPM doesn't work? And if so, can't I put the SPM in the boot section and run it from the application code using a function pointer?

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

The reason our FAQ says that is that usually there isn't room for two botloaders but the Xmega case (I believe) is a little different. As I understand it they have a fixed size, separate area of flash for the bootloader and you may or may not be using all of it. If you are using less than half then clearly you would have room for two bootloaders (actually they don't have to be the same size - the "replace bootloader bootloader" may be "minimalist and use less space.

Compare this situation to that of mega where typically you had four selectable sizes for the bootloader and these "ate" into the application space. So in a chip with 16K you might have the option to have 0.5K, 1K, 2K and 4K bootloaders. But this would leave 15.5K, 15K, 14K or 12K. So one always tried to get the bootloader code to the smallest size possible then set the boot position to be the highest possible and still contain it. This almost always meant that there were never more than a few hundred bytes spare (if that!) and not much possibility of squeezing in two bootloaders.

So like a lot of the articles in the Tutorial Forum, many written before Xmega, you have to read them in the context of tiny/mega usage - not Xmega.

Atmel have actually done the developer a favour by just putting in more/separate flash for the Xmega bootloader so the situation is different.

BTW it's because SPM only operates in the bootloader section of flash that the code to bootload must exist there. You can however have (admittedly dangerous!) strategies where some of the bootloader is not in the bootloader area itself and only the SPM routines are. But this is fraught and should only be considered if you cannot fit two.

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

Thanks.

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

Another reason for 'NO' is that once you program your bootloader with a programmer, it is recommended that you lock the bootloader flash area against writing, so a buggy application firmware will not corrupt the bootloader. Once you do that, you can no longer write another bootloader there unless you erase the chip and reprogram it with a programmer.
George.