wiki:Stuff/FirmwareUpdate

Version 26 (modified by art, 13 years ago) (diff)

--

Firmware update

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 len FF FB 01 12 d3 d2 d1 d0 ss rr rr rr rr chk, where:
    • 01:12 - major version 8bit = 1:01, minor version 8bit = 18:12 -> 1.18
    • d0-d3: device id as 32 bit number
    • ss - size in bytes of mximum 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 of up-to a variable length of up-to 128 bytes: FF 24 F0 FA FF pp pp pp ... pp chk (password is specific to every OpenBM unit)

  • if password was correct bootloader answer with: F0 05 FF FB hh ll chk, where hhll is a 16bit number representing the sum of all password bytes:
    • 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)

Programming

  • Host application must send an Init-Chunk-Message: FF 0A F0 FA FF vh vl nch ncl s2 s1 chk, where:
    • vh:vl - major and minor version numbers of the new firmware
    • nch:ncl - is a 16 bit number indicating number of the firmware chunks
    • s2:s1 - 16 bit seed number (can be any random number)

  • OpenBM acknowledge each chunk (incl. init chunk) with a message: F0 07 FF FB cnh cnl s2 s1 chk, where:
    • cnh:chl - last received chunk number.
    • s2:sl - seed number received in the init chunk "xor"ed with the 16bit sum of the chunk data written to the flash
    • "Init"-chunk is acknowledged by 0 chunk number and the same seed received in the init chunk
  • Host application send now data chunks. The chunk size should be either 32, 64 or 128 bytes, FF len F0 FA FF cnh cnl c1 c2 .. cn chk, where:
    • cnh:cnl - number of the chunk, this number should be increasing with every chunk (so no random access here is possible!)
    • 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 06 F0 FA FF 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 04 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