Upgrading the Firmware/Application

Top  Previous  Next

As was explained under Direct Sector Access, you can't use fd.setsector to write to the flash area occupied by the firmware and Tibbo BASIC/C application. This is done to prevent your application from inadvertently damaging its own code or the firmware.

A special fd.copyfirmware method is provided for changing the data in the firmware/application area of the flash. The method copies the specified number of sectors (starting from the logical sector 0) from the data area and into the firmware/application area of the flash memory (starting from the physical sector 0), then reboots your device.

Before invoking this method, store the new "binary image" of the firmware/application in the data area of the flash memory starting from logical sector #0. Logical numbers are assigned to the sectors in reverse, so using fd.setsector to write to logical sector #0 actually means storing to the topmost physical sector of the flash memory. It goes without saying that your data area has to have enough capacity to store the new binary image.




The diagram above presents the case of the shared flash memory. With dedicated memory, the fd. object uses a separate flash IC to store its data. The size of this flash IC must be large enough to store the new firmware/application that you want to "activate" with the fd.copyfirmware method.


Exactly how you receive the new binary image is immaterial to this discussion. You can use any suitable transmission method, such as TCIP/IP, FTP, your own proprietary protocol, whatever! The important part is that before invoking fd.copyfirmware you must have the binary image stored in the data area of the flash, starting from the logical sector #0, and you must know how many sectors this occupies. After that, invoke fd.copyfirmware and hope that you prepared the right data!


Another method — fd.copyfirmwarelzo — does the same job but assumes that the data prepared in the flash memory is not the binary image itself, but an LZO-compressed version of the same. This method will unpack the binary and copy it into the firmware/application area of the flash memory. Because the compressed data is not sector-aligned, this method takes the compressed data size length in bytes, not sectors.

Use "compressed" firmware upgrades whenever you are dealing with a sizeable Tibbo BASIC/C project. On devices with shared flash memory, such projects will leave you with a small amount of free flash space, so the uncompressed "upgrade binary" will probably not fit there. In such cases LZO compression may be your way out, as it can achieve 30-50% reduction in file size.

The decompression algorithm accepts files compressed with lzo1x-999.exe utility.



BE VERY CAREFUL! Using fd.copyfirmware or fd.copyfirmwarelzo on incorrect data will "incapacitate" your device and further remote upgrades will become impossible. You will need to physically go to your device and upload correct firmware and/or application, possibly through its serial port. Scary, huh?