Reprogramm the Bootloader from Application Section

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

Hi,
Could you help me to give me some instructions how I can manage the following problem? 

Background: There are some smart meters which are operating somewhere in Africa. It takes 2 to 3 days to update the firmware (using the Card reader on that meter. It is reading the firmware from a 64kb Chipcard ) on the meters. Shortly we upgraded our meters with a Xbee module. So the idea is to reduce, the three days with using the radio communication to send the firmware.

Challenge: I'm not able to rewrite the bootloader with an ISP programmer.  I read that, some page(on the bootloader) is holding the sp instructions and it shouldn't be erased. How could I identify that page? 
The current bootloader reads the 64Kb chip card and rewrites the application pages.

 

 

What I want to do is: Write a program which is acting as an application. So the bootloader is going to write it on the flash (application section). After that, the program will rewrite all bootloader pages. So I have a new bootloader. 

 

 

The main application will be wiped out of our meter, but the bootloader will wait until the XBee gateway starts to send the current firmware.

 

 

Thanks.

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

The SPM opcode is only active in the bootloader section so any code that is going to write flash MUST be positioned in the bootloader area.

 

A few times we have seen threads here where folks have managed to deliver a second bootloader to an AVR that alredy has an active bootloader and then used this second one to replace the first one. So it can be done.

However it requires a few things:

 

1) the existing bootloader must already have the ability to write to addresses in the bootloader section. A lot of existing bootloaders have an added protection (over and above the lock bits) to not allow a destination address that is above the bootloader section address

 

2) talking of lock bits - the lock bits that can protect writes to the bootloader section must not be active

 

3) to deliver and use a second bootloader there has to be room for it in the bootloader section.

 

If some/all of these conditions cannot be met then your best bet is to deliver the second bootloader to the top of the application flash section but when it comes to actually doing the SPM operation it calls to the existing SPM routine in the 1st bootloader. Whether that SPM has been isolated in such a way that can be easily called is another good question!

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

Thank you very much for your answer. 
1. The current bootloader is designed only to reprogram the application section. 
2. The lock bits aren't enabled 
3. The current one is 2 Kb. So there is room for the second but as I mentioned the current one is starting from a defined address to write.

The only option which is left is to place the second bootloader on the top of the application and try to find a way to use the SPM commands.