Over the air programming

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

Hi,

we've just started to investigate the possibility to update the firmware on our sensor nodes over the air (3G/GPRS). Basically we would like to download a new firmware from our servers, update the application section of flash, and reboot with the new firmware.

After a little reading on self programming (app note from Atmel) and bootloaders we're still a little lost in the terminology.

Has anyone had any experience with this kind of approach with the Xmega (we're using the Xmega256A3). Any suggestions on a first approach to get up and running with a simple test over USART or similar? Any good tutorials or documentation on this (except for Atmels app notes)?

Best regards
Fredrik

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

Why limit yourself to Xmega's? All that's written about bootloaders for tiny/mega will apply equally. The main difference for X is where the bootloader actually locates but that's just a different address at the end of the day. As you are probably aware most existing bootloaders are written assuming a direct UAT connection to a PC so the only bit that differs for 3G/GPRS is the call setup stuff to open the data channel to the server providing the binary. But after that it's the same "receive some bytes, SPM a page, rinse and repeat".

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

clawson, thanks for the quick response. You suggestions sounds resonable, but since 3G/GPRS is such an unreliable link, we would like to first download the application, verify a checksum, and then update our firmware. In the long run we would actually like to keep the old version of the firmware until we manage to connect to our servers with the new version, and revert if it fails. Since we're not that experienced when it comes to bootloaders, this will we a project to start on once we get a basic bootloader that updates our firmware running.

So, for now, we would like to download an image (intel hex?) from our servers to our SD-card on the node, reset the unit, let the bootloader replace the application section with the image from flash and then run the app.

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

As long as you have the storage medium for the firmware such as SD then that sounds eminently feasible.

To be honest I worked for a company that was delivering advertising media (megabyte .mpg and .swf files) over GPRS and link integrity was never a real issue (though it's true we had a system to receive and MD5 the files to be sure).

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

I like cats, too. Let's exchange recipes.

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

One method I know of that was used successfully required an external flash memory and the firmware was written to this memory over the air. The bootloader on the chip, which never changed, would determine if and which firmware was to be installed into the chip's flash memory and would do so when reset or powercycled. Because the chip segregated internal flash you could execute code from one section while another was being erased and programmed. As you mentioned there was a known working version and the newer version of the code on board. If the new version proved to be broken the older version could be easily reinstated.

Another method I have used in the past involved copying from ROM to RAM and executing the flash burning code out of RAM while the flash chip was tied up being erased and reprogrammed. This was a DSP system though that used another chip connected to the host port interface to feed it the ROM data.

You really need to think hard about all the possible modes of failure of remote programming and be able recover from them without needing to send a person out to the unit to perform maintenance - which can get expensive and time consuming.

And test the bejesus out of the code too in the lab before you deploy it. Avoid reprogramming remotely at all costs, don't fall into the trap of feature creep and constant upgrades just because you can. And did I already mention testing? Regression testing is too damned important when doing this, trust me, I know (like system buggering stack overflows that only happen when the moon is aligned with Venus on Tuesdays - but it happens).

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

Quote:

don't fall into the trap of feature creep and constant upgrades just because you can

Wish someone had explained this to our management on previous projects I've worked on :?