Update firmware via gsm

PaulF

Hi all,
I'm putting the finishing touches to a commercial prop based app. and I would like to include a facility where I could remotely update the firmware (eeprom file) using mobile phone (cell phone) technology.
Has anyone done anything similar and if so, any suggestions as to what is involved, code wise, external components, problems/issues etc?
Thanks

Paul

Baggers

Hi RivTec, there's slight problems with updating the firmware over gcm, if the signal gets disconnected etc, you're stuffed, as you don't have enough ram, to check that it's all received correctly etc.

The only way I can think of to do it safely, is to have add a second EEPROM where you can put the new downloaded code, until it's received with checksum, and check the completed transfer for errors, then program the main EEPROM with this new code.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite

·

Jetfire

Baggers is right, transfer robustness can be a big problem here. For this reason, you probably don't want to use the bootloader for programming the eeprom. If you used a 64K eeprom you could load chunks at a time into the second half. After everything is in, the eeprom is verified, copied into the booting portion, then the prop is reset.

PaulF

Thanks guys, I was thinking of using the upper half of a 64K eeprom as you both suggested. But it's probably more the hardware that I will need to use that I am having the greatest difficulty with at the minute.

dMajo

Baggers said...
The only way I can think of to do it safely, is to have add a second EEPROM where you can put the new downloaded code, until it's received with checksum, and check the completed transfer for errors, then program the main EEPROM with this new code.

·Or use an I2C/SPI persistent IO to switch the addresses of the two eeproms choosing from which-one to boot next time [noparse]:)[/noparse]

Drone

There an MD5 hash spin-only object by darco in ObEx that may be of some use to verify the code upload:

obex.parallax.com/objects/321/. I haven't tried it myself though.

Remember you don't want to write to EEPROM often for months or years on-end as they may wear out [noparse][[/noparse]10's or (typically) a 100 thousand write cycles for standard parts]. But that probably won't be an issue. If it is; there are some high-end flash memory cards that have "wear leveling" and/or error correction capabilities built-in. From previous posts I've seen, it seems fairly simple to use the likes of an SD card with propeller for storage.

Regards, David

Phil Pilgrim (PhiPi)

I'm afraid I don't get why the additional EEPROM is even necessary. A cog-resident bootloader can download the new code to RAM, check it for correctness, then program the EEPROM. Just be sure to include the bootloader in the EEPROM image each time as the top-level program. Upon reset, it will check for a BREAK condition on the serial input and, if it sees one, begin the loading process. If no break exists on reset, it will start the cog of the user's top-level program and exit. The user's program, if it uses serial I/O could also include a BREAK detector, which would then reset the chip, thus reloading the bootloader.

As an alternative, the bootloader could download the program (sans bootloader copy) in to RAM and store it in EEPROM at an offset address from the space the bootloader occupies. Then, upon reset, the same check for BREAK; only this time, if it sees none, it reloads RAM from the offset EEPROM, zeroes the leftover space at the top of RAM, and starts the cog at the first RAM location. I've used this latter method, and it works.

-Phil

mctrivia

I wrote an open web page that lets you store eeprom images(up to 32MB) and download it in pages.

http://prop.aigamez.net/

I have not yet writen the code for the prop to download but I have notes on the pages use here

http://forums.parallax.com/forums/default.aspx?f=25&m=324680

Baggers

Phil Pilgrim, say your eeprom needs all 32KB ( yes I know not overly likely )
but you'd need some HUB-RAM space for your GSM + Bootloader + MD5 data space, plus any spin in required for glueing together, plus you'd have to make sure the ram buffers were high up, and not in where the overwritten new code would be.
which is why I suggested the extra / or upper EEPROM as JetFire suggested, just to safeguard any code currently in hub-ram

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite

·

Phil Pilgrim (PhiPi)

Baggers,

Typically, the upper end of a program whose code and variables use 32K will be zero anyway, so this can be zeroed when the program is offset-loaded into RAM from EEPROM. At least that's the way I do it. My bootloader uses no hub RAM at all. I'm unfamiliar with the GSM code requirements, though, so perhaps this is a killer, space-wise. As to MD5, there are sure to be less involved, but nonetheless adequate, redundancy checks that could be performed using cog memory. But even with MD5, there are 16K bytes of cog RAM available, spread across 8 cogs and accessible with minimum-footprint ASM accessor routines that can use a few bytes of upper hub RAM for comms.

-Phil

Baggers

Yes, I know all that Phil, heck, you could even have a cog hold the memory you overwrite, and bring it back once it's done, but I wasn't sure of PaulF's abilities, as he's only posted 48 posts [noparse]:)[/noparse] even though he's doing something none noob so to speak.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite

·

PaulF

Hi Baggers,Phil et al,
thanks for all your advice. I have limited 'knowledge' in relation to spin and practically zero in relation to asm. Anything I have done to date is with a lot of help from this forum. The app I refer to uses fsrw, fullduplexserial and basicI2C. I cannot say that I understand everthing about these objects, but I have 'managed' to get them to work together. I have managed to get the program update itself from the SD card, but I just thought that it would be cool to upgrade via GSM (and easier/better for me to monitor/control the upgrades).

Paul

PaulF

Hi,
I've been otherwise occupied since I posted my request for help. Again thanks for all the useful advice, however could anyone advise as to a suitable gsm card/module/chip etc that will allow me to communicate with the propeller for the purposes of updating or checking the status of the device.

Paul

dMajo

PaulF said...
Hi,
I've been otherwise occupied since I posted my request for help. Again thanks for all the useful advice, however could anyone advise as to a suitable gsm card/module/chip etc that will allow me to communicate with the propeller for the purposes of updating or checking the status of the device.

Paul

There is some treads in the propeller forum discussing the gsm module argument.

But, if this is a commercial application, I suggest you to go with a serial port and interface that with an external gsm module (you will find many of them available from many vendors for several temperature ranges and IP grade protection). This will leave also the opportunity to use gsm/umts/radio/classic56k modems and, why not, a virtual tcp/ip serial port on internet/intranet network.

PaulF

Hi dMajo, this sounds like a good idea. I will look into this further, thanks.

Paul

dMajo

Just had the opportunity to evalutate (in a team collaborative development) a WiFi module. It was good (even if for lan connectivity I usually use lantronix products). The guys choose that because of the socket type and the possibility to easily exchange the connectivity media. It supports also gsm, but I have never used it.