Firmware updates
T Chap
Posts: 4,198
With a PC or Mac, any suggestions on how to update the Propeller without exposing the user to the PTool? Replacing an eeprom is not a good option either. Ideally, some way to get the complied version of code into a fie that can be sent to the user(email, download etc), along with a proprietary app that will update the program semi-automatocally.. load the app, read the current revision from the Propeller, and press "update" if required.
Comments
I can create a standard C console application (exe and dll) to do it, so you could embed the software inside your own GUI easily. You would call it with the string to search. For example :
PropCheck.exe -com 4 -version PROPV -format N.NN
Com : Com port to use
Version : String to search inside the downloaded binary data
Format : Format of the version
This would read the EEPROM in a buffer and search for your version string and return the version according to your format... Then, you could call
PropDown.exe -com 4 -file newsoft.bin
Com : Com port to use
File : Binary data to upload
This would download the binary data to your prop eeprom on com port x.
Have a nice day,
Simon
I am going to assume you are using some sort of serial interface for the connection to the computer for a firmware update. That would mean that you should be able to add a sort of command that could be sent to return the current firmware version (which should be a const in your props program) and another command to accept chunks of information to be written to the eeprom along with some simple error checking.
For a little extra security when distributing your firmware file, you could make a pc program to modify the binary data to add extra data as in a header and regularly spaced fix lengths of data that can be removed at update time. Hmmm I guess you could even do some simple encrypting with the prop setup to decrypt.
Oh well it seems you have some options on the way you want to go (unless I'm completely mistaken about the prop)
-Matt
However, with the propeller, the bootloader would be with the same memory as the software, so it becomes very dangerous, if you start writing data to the eeprom and the transfer is interrupted or there is too much noise for some reason, your software will never boot again.
I have seen a lot of products that when downloading, the warning appears: "Do not disconnect or turn off power during download". In case of the mishap, replacement of eeprom is not a big deal.
Here is something to ponder off topic, but related to downloading and encryption. The FTDI usb to serial chip(FT232RL) is able to be read for it's embedded serial number. The chip's documentation has info on using the chip strictly for ID purposes, or as we call a dongle, to determine if the product or software is registered. If the seral number fails, they aren't regustered. I was wondering if the Prop could read the serial number as well, but likely not as the PC requires a DLL to execute the commands. Anyways, I thought it maight have some usefuless in a hardare approach towards piracy protection. For example, if the dongle was not present, the Prop wouldn't run. If am noy mistaken, the eeprom cn be written to as well with the product name and version. I don't a solid idea, but maybe some combination of FTDI and Propeller could be used for both version tracking and updating that includes anit an anti-piracy feature. Another application of this feature is that without the dongle plugged in, no one could update the program. Maybe useless ideas, but who knows what may come up.
On every reset, the bootloader scans the serial port for some time (say 1 second) looking for a special character pair or something.
If seen, it just reloads the upper part of the EEPROM from the serial stream (with appropriate checksums, etc.).
If the character pair is not seen, the chip simply loads the upper half of the EEPROM into the propeller memory and executes that.
The user procedure would be: connect the prop to the serial/USB port, start this program (which just sends char pairs to the serial port
until it gets a response, then downloads the app), then hit reset on the hardware. It would be nice to have a pretty blinking light
saying okay or not.
Of course, USB might be a tad painful since the customer would have to install the FTDI driver, so just forcing the use of a serial
port might be the easiest thing to do.
Another way to do it is to do away with all connections entirely; put a photodiode in the product, have the customer hit reset and
hold the hardware up to the screen, and have the data be sent over the video by flashing an area of the screen on and off.
Most operations as far as programing the prop is going to result in trouble if you loose power but the 64K EEPROM chip sounds like a neat idea (does the prop work that way?)or even 2 32K chips the bootloader chip having the WP set to keep from any mishaps. Using a method like that would allow you to add more than just a bootloader to the first 32K, like a HW debugger and routines to decrypt the incomming encrypted firmware (if you chose to do something like that). Even add copyright protection of some sort to that part, so that if they did mess with the incomming firmware they could bypass the copyprotection without opening the box/case of your product.
I had this issue earlier and with help from Chip's documentation and others I wrote a Python script that can load a binary image into the propeller without using the propeller tool.
Here's a link to the original posting.
http://forums.parallax.com/showthread.php?p=611536
I've used it on both Windows and Linux, and I've been told it worked on a Mac as well.
-Chad