Software erased during use with xboot

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

My xmegad64 based product uses xboot as serial bootloader and so far I haven't had any problems with it. But now my customer reported that the unit didn't work anymore and was just flashing one LED. After inspection I found out that there was no problem in hardware, EEPROM, FUSES nor bootloader, but the whole application area of FLASH was just empty (all 0XFF). The customer told that this happened while they were in connection with the unit through telnet and they had used the sequence to reboot the device thus entering xboot for a while before rebooting. Xboot uses AVR109 protocol, which I haven't really studied, just used with xboot + avrdude. Is it likely that the customer has accidently given an erase command through telnet (with keyboard!) or how was the program erased?

 

The product works just as normal now, after I programmed the FLASH again using avrdude via xboot.

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

In AVR109 the letter 'e' performs a chip erase. I imagine it might be quite possible for someone to have issued this if the chip hat reset into bootloading mode.

 

I guess a "safer" protocol would have been one that takes a command packet that includes a CRC. It would probably be trickier to send both 'e' and a CRC that validated it.

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

Thanks, that was easier than I thought. I just have to wonder this hasn't already happened to me while testing.

 

Is there a recommended serial protocol, which both avrdude and xboot (or some other bootloader) works with and would not be that easy to fail. The programming must be done purely through serial port, thus not by pressing a button or by cycling power (software boot is needed of course).

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

I decided to modify xboot. Now it needs a longer sync string instead of just ESC. Thus it also needs this string sent before running avrdude, since I didn't want to modify avrdude. Using sync codes above normal ASCII range made it even backward compatible, thus the new firmware update system can be used with old boot loader.

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

Do I understand that the bootloader erased the application flash?   That's what it is supposed to do before it reprograms the application flash.

 

 

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

Steve, 

 

No I think he's saying a human was typing at the AVR when it reset into bootloader mode. Presumably the user hit 'e' and the bootloader took that as an instruction to "erase chip" so it did. The issue is that AVR109 makes it too easy to issue powerful commands like this. 

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

Xboot needs only 'ESC' + 'e' and even the need of 'ESC' depends on configuration.  'ESC' activates the bootloader and it takes AVR109 commands until watchdog boot or exit command.

 

That is way too easy to erase by human + keyboard or a software. Usually I use different baudrate for the application and the bootloader, which makes it much less likely, but my customer uses the same. Probably there are other dangerous commands as well in AVR109, which may not be so easy to detect as "chip erase".

 

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

I think I get it.  This method of entering the bootloader insures the user can always get to the bootloader and never have to push a button.

 

I guess the bootloader would immediately go to the application unless the reset was power on or maybe software generated.

 

If Xboot is like the one I use and it erroneously thought it saw a write command, that could be a disaster also.

Last Edited: Sun. Mar 1, 2015 - 01:16 PM