Jump to content
larsie

Over the air programming

Recommended Posts

I have a board with msp430g2553 and a cc1101 radio module. I would like to program the msp430 over-the-air. Is it possible? If so, what would be the easiest way to do it. I am on thin ice when it comes to boot loaders, flash, even memory addressing, so tell me slowly and with simple words :)

 

The program is about 5k so less than half of the total flash size on the chips.

 

Sent from my GT-I9505 using Tapatalk

 

 

Share this post


Link to post
Share on other sites

For embedded RF, the best way to do it is to have double the Flash necessary, and then just load the new firmware into the other half of flash.  Once it is fully loaded, restart.  Your bootloader can be tiny, it just needs to jump to the newer half.  One thing, however, is that you will need two builds of the firmware: one built to start at offset A and the other at offset B.

 

Another thing you need is a radio layer that is robust against data errors.  built-in CRC on the 1101 isn't sufficient unless you are using fixed-length packets. If you are using variable length packets, you need to find a way to protect the header with its own CRC, and even then you might want an internal CRC32.

Share this post


Link to post
Share on other sites

Felix at lowpowerlabs has set it up on his moteinos(Arduino minis with RFM radios) using an SPI flash module and a modified bootloader that looks for hex records in the flash when it starts.  He has some posts and links to his github here:  http://lowpowerlab.com/blog/category/moteino/wireless-programming/  

 

Hopefully his explanations and codes samples will be helpful (I am also on thin ice regarding this stuff).

B

Share this post


Link to post
Share on other sites

Another implementation.

 

Make a stripped down version of your code. that can just respond to OTA commands. This would be your bootloader. It would run until a new firmware was flashed in the flash below it. 

 

On boot, this code would run first and only run your actual firmware if it's CRC was good.

 

I was trying to find some articles that show the memory map. But I can't seem to find the ones I'm thinking of.

Share this post


Link to post
Share on other sites

Thanks. Would the program that's uploaded have to be adjusted so that the addressing is right? I mean, the boot loader would be first, right? And then the program would follow (either as a bootloader with a program, or the 'dual-program' as suggested). Or would I compile the program with the boot-loader in front and the rest of the program after, so that the addressing is correct, and then just upload the relevant bits to the chip? 

Share this post


Link to post
Share on other sites

Have you seen this thread?

 

http://forum.43oh.com/topic/3661-1k-serial-gdb-bootloader/

 

There are many hints in that post about how to do bootloading and hiding yourself in memory.  To do over the air instead of serial, you would have to implement the read and write routines for CC110L instead of a UART.  The nice thing about using GDB for something like this, the Remote Serial Protocol (GDB RSP) already takes care of the CRC and ACK/NAK.  In addition, someone else did the host side coding for you. All you need is msp430-gdb for your host.

 

-rick

Share this post


Link to post
Share on other sites

Thanks. Will look at that post. But I don't have serial access from the radio-module. I have to run the radio module as a master, using SPI from the microcontroller itself. 

Share this post


Link to post
Share on other sites

the Remote Serial Protocol (GDB RSP) already takes care of the CRC and ACK/NAK.

Just a note: CRC is not totally fail-safe.  There is a hamming distance that a given code is guaranteed to protect against, over a known payload size.  Most implementations of CRC over a variable-length payload are actually broken, though, and their hamming distances are effectively 1.  Better to use fixed-length packets or a header with independent CRC protection.  The problem is that, if the length byte is in error, the resilience of the CRC goes way down.

 

Other notes:

  • The CCITT variant of CRC16 is lousy.  It's the one with polynomial usually represented as 0x1021 ( x^16 + x^12 + x^5 + 1).  This is what is implemented in many MSP430 cores as a peripheral, so it is wasted die area as far as I am concerned.
  • The IBM CRC16 poly is good for payloads up to 256 bytes.  It is 0x8005 (x^16 + x^15 + x^2 + 1).  The CC1101 implements this in HW.
  • You can implement CRC32 by a 1KB lookup table, and compute the checksum over the entire FW image if you like.

 

I'm giving you this advice as a guy who has seen catastrophic failures in HW due to OTA FW transfer using broken CRC implementations!  It is amazing what a single bad bit can do: in this example I'm thinking of, it resulted in bricking, but I know folks who have had HW catch on fire!   :)

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...