Firmware update
TracNav
- Home
Hardware
- Reverse Engineering
- Encoders (code)
Manufacturing
Development
- First prototype
- Second prototype (SMD version)
- Emulating MID
- HW1.0-beta1 (third revision)
- HW2.0 (4th revision)
CarPC
Software
Stuff
User projects
Firmware
As the firmware we call the software running on the OpenBM device, so which is programmed into the uC to control the button fields. Here I would like to show a protocol which I developed in order to update the firmware of the OpenBM device through IBus. Hence no extra hardware is required. A special application can send the firmware using this protocol to the OpenBM device. If sending was ok, no error, then the firmware will be written to the device flash.
Bootloader
Since I am using AVR ATmega32 as the uC the update of the firmware can only be done in the bootloader mode. Special code is written to the bootloader section of the uC and is executed on the start or reset. The bootloader checks for special commands and if nothing received it passes the execution to the main software. So in order to activate bootloader mode on the OpenBM device we do following:
Initialization
- reset OpenBM manually or by an ibus message:
- manually: hold MENU+SELECT+EJECT and the release MENU
- ibus command: FF 07 F0 FA BA AD FE ED .. (dst = BMBT:0xF0, src = FF(ignored), msg = OpenBM_Request:0xFA, data = [0xBA, 0xAD, 0xFE, 0xED])
- OpenBM send version information of currently flashed program as a message over the ibus: F0 0B FF FB FF 01 12 ss rr rr rr rr chk, where:
- 01:12 - major version 8bit = 1:01, minor version 8bit = 18:12 -> 1.18
- ss - size in bytes of maximum allowed chunk size. Any chunk must be of a power of two size smaller or equal to ss
- rr - reserved bytes
- now we have around one second time to send messages over ibus to set bootloader into "Firmware Update" mode:
- send "Activate_Update_Mode" message incl. a password must have a length of 4 bytes: FF 08 F0 FA FF pp pp pp pp chk (password is specific to every OpenBM unit)
- bootloader answer with: F0 05 FF FB 00 hl chk, where hl is a 8bit number of xored password bytes sent previously:
- bootloader is activated and Yellow LED lights on
- bootloader is deactivated if it not receive any firmware code chunks for the next 10 seconds (If boot loader is deactivated, Yellow LED turns off)
- bootloader is also deactivated, when full firmware code was transmitted (see next section of how to transmit firmware)
- bootloader is always accepting firmware, even if password was incorrect. At the end of firmware uploading process bootloader submits a CRC-16 checksum of send decoded/written firmware. This must be checked against the checksum received with the firmware, if it was incorrect the firmware must be retransmitted.
Programming
- Host application must send an Init-Chunk-Message: FF 09 F0 FA FF vh vl ch cl ss chk, where:
- vh:vl - major and minor version numbers of the new firmware
- ch:cl - CRC16 checksum of the firmware delivered with the firmware file
- ss - 8 bit seed number (can be any random number)
- OpenBM acknowledge each chunk (incl. init chunk) with a message: F0 04 FF FB sc chk, where:
- sc - seed number received in the init chunk "xor"ed with the "xor" sum of the chunk data written to the flash
- "Init"-chunk is acknowledged by the same seed as received in the init chunk
- Host application send now data chunks. The chunk size should be a power of two number by which the maximum allowed chunk size number (ss) is dividable (i.e. 8,16,32,64,128), FF len F0 FA FF cnd c1 c2 .. cn chk, where:
- cnd - special chunk indicator (0x00 -> Repeat last chunk, 0x10 -> next chunk, 0xFF -> last chunk)
- c1:cn - chunk of firmware data
- Every chunk is acknowledged by OpenBM device. If acknowledge was wrong (host app should check the seed number), host application can resend the last chunk or stop transmission.
- Host application stop transmission by sending a "Stop"-chunk: FF 05 F0 FA FF FF chk. So send this after last chunk was acknowledged.
- OpenBM bootloader indicate that it does not accept any data anymore by sending: F0 05 FF FB eeh eel chk, where:
- eeh:eel - 16bit error code: when everything went right, we receive 0=OK, otherwise we receive an error code. Check bootloader documentation for error code definitions
- When last chunk was received, OpenBM checks if the fimrware CRC16 is equal to the given crc16 number in the init chunk. If it is not equal, then bootloader restarts (indicated by a version string send again). Otherwise main application will boot.