Jump to content
Sign in to follow this  
brainwash

RF bootloader

Recommended Posts

I'm trying to build a home automation system and would like to be able to update the firmware on the nodes remotely via the NRF24L (SPI) module. Either that or go with an embedded scripted language but I don't know anything that would fit into an MSP430G (eLua, Python, TinyBasic) that's why I would rather go with the remote bootloader approach.

Or are there any other ways to implement a simple scripted language? Something like: if (ADC(P1.4)>20) then (P1.5=1). I could always use a Stellaris and load everything into RAM but I'm trying to go with the lowest-end solution.

Share this post


Link to post
Share on other sites

Hmm, what do you want to do with it?  Could probably roll your own nRF24-based protocol with simplistic binary "commands" like... GPIO set, GPIO read, SPI write, SPI read, etc. and implement the firmware to carry these out & report their results.  That would be a tiny (binary) "scripting" language of sort turning your G-series MSP430 into an nRF24-attached remote slave.

 

Note that this all requires the nRF24 to stay in PRIM_RX mode all the time, ~14mA power draw, somewhat negating the ULP features of the MSP430.

Unless you got fancy and had these devices go to sleep & wake up periodically to "check in" with a plugged-in base station to see if any commands are waiting for that remote node's execution.

Share this post


Link to post
Share on other sites

The idea is very interesting, but not sure if it's really necessary. I'm doing something similar but my system requires a running linux system as the "server", sensors just send information to the server and you can define actions and complex conditions on server side, using whatever advanced scripting language you want. It will greatly lower down the power consumption and cost of each sensor node. The server can be a raspberry pi, or even an arduino board.

Share this post


Link to post
Share on other sites

Maybe somewhat of a hybrid of your two options: use PIC (position independent code)

 

With PIC you're able to write snippets of binary code to the  MSP430 and execute them. Your execution framework (the main MSP430 application) will call upon one of such functions which gets executed as native code. A drawback is that you cannot (usually) use libraries; your code snippet needs to be fully selfcontained. This means you can do if (P1IN & BIT4) then (P1 |= BIT5); But you cannot do if (getADC(P1IN,BIT4)>20) then (P1 |= BIT5); because this would rely on the existence of an ADC() function.

There are two approaches: link the ADC() function with each piece of code you will use, pass a pointer to a baked in framework.

The first approach will maintain the premise that the snippet is selfcontained (and only relies on the memory layout for your peripherals)

The second approach will enable the use of libraries, but requires you to keep track of which library is running on which platform, or to manually flash each device again after altering the library.

Share this post


Link to post
Share on other sites

I've done this.  Indeed, it's not a trivial problem, but it's actually a lot easier that some other problems in wireless.

 

Do you simply want to be able to upload a new sketch wirelessly, or do you want to be able to update EVERYTHING wirelessly?

Share this post


Link to post
Share on other sites

I've done this.  Indeed, it's not a trivial problem, but it's actually a lot easier that some other problems in wireless.

 

Do you simply want to be able to upload a new sketch wirelessly, or do you want to be able to update EVERYTHING wirelessly?

How did you deal with the security aspect of this? Seems like you would have to be careful not to let rogue updates happen.

 

-rick

Share this post


Link to post
Share on other sites

How did you deal with the security aspect of this? Seems like you would have to be careful not to let rogue updates happen.

 

-rick

AES128-CBC, but that is something the wireless MAC handles in my case.  My devices have a filesystem implementation (it is very light, though), with user privileges.  So, to write to the firmware image sector, you need to have the right privileges.

 

BTW, everything I do is linked below.  Not everything is open source ATM, but you'll get the idea.  CC430/MSP430F5 has a helpful AES peripheral, and STM32 is fast enough to crank it out in FW, faster than 1us/byte.  Those are my main platforms.

 

But, if you're just a hobbyist, nobody is going to know your protocol.  You are pretty safe.

Share this post


Link to post
Share on other sites

We actually have an application note that outlines a wireless update system on the Fraunchpad.  Check it out: http://www.ti.com/lit/an/slaa511/slaa511.pdf

I know the engineer who worked on this personally, so if you have any questions, let me know and I'll see what I can find out for you.

Why do so many of the samples from TI require you to login to download? And why do you distribute them as .exe files?

 

I was going to look at this but .. meh.

 

-rick

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.

Sign in to follow this  

×
×
  • Create New...