Benutzer-Werkzeuge

Webseiten-Werkzeuge


canboot
Firmware
Step From To Message
A.1 Mqtt Hub 't5/reboot/' nr: deviceno
A.2 Hub Client REBOOT(0x270|nr), len=4, data=REBOOTREQUEST(3):8,:8,deviceno:16
A.2 Client Hub Application sends final heartbeat, then reboots into canboot via watchdog
B.1 Client Hub JSON(0x240|nr) '{"topic":"canboot","id","sw","mcusr","avr","f_cpu","f_mcp","spi"}'
B.2 Hub Mqtt 't5/status/' nr: Text received from client
B.3 Client Hub FIRMWARE_ACK(0x130), len=4-5, data=FIRMWAREREQUEST(2):8,VERSION(0x10):8,deviceno:16[,mcusr:8]
B.3a Client Hub REBOOT(0x270|nr), len=5, data=FIRMWAREREQUEST(2):8,VERSION(0x10):8,deviceno:16,mcusr:8
B.4 Hub Mqtt 't5/boot/' nr: '{"id":' deviceno ', [',"mcusr":' mcusr] '}'
C.1 Mqtt Hub 't5/firmware/' deviceno ('/flash'|'/eeprom'): hexfile
D.1 Hub Client FIRMWARE_CONTROL(0x100) len=5, data=version(0x10):8, 'E'|'F':8, deviceno:16, 'B':8
D.2 Client Hub FIRMWARE_ACK(0x130), len=2, data=ack(1)|nack(0):8,VERSION(0x10):8
D.i Hub Client FIRMWARE_CONTROL(0x100) len=5, data=addr:32, 'A':8
D.i+1 Client Hub FIRMWARE_ACK(0x130), len=2, data=ack(1)|nack(0):8,VERSION(0x10):8
D.j Hub Client FIRMWARE_DATA(0x110) len=1-8, data
D.j+1 Client Hub FIRMWARE_ACK(0x130), len=2, data=ack(1)|nack(0):8,VERSION(0x10):8
D.n Hub Client FIRMWARE_CONTROL(0x100) len=5, data=frames:16, crc:16, 'E':8
D.n+1 Client Hub FIRMWARE_ACK(0x130), len=2, data=ack(1)|nack(0):8,VERSION(0x10):8
E.1 Client Hub JSON(0x240|nr) '{"topic":"canboot","id","state","framecount","edaddr"}'
„state“ can be AWAITING_BEGIN(1), AWAITING_DATA(2), AWAITING_BOOT(3), DONE(4) or DONE_MUSTMOVEFLASH(5)
E.1a Client Hub JSON(0x240|nr) '{"topic":"canboot","id","nies","fc","ea"}'
„nies“ is a combination of nack, intf, eflg and state. State can be AWAITING_BEGIN(0), AWAITING_DATA(1), AWAITING_BOOT(2), DONE(3) or DONE_MUSTMOVEFLASH(4). For intf and eflg refer to MCP2515 datasheet.
E.2 Hub Mqtt 't5/status/' nr: Text received from client

Note:

  1. Clients booting for other reasons than being requested via A.2 would begin the sequence at step B.1.
  2. Some clients (T3/T4) implement firmware reception within the application. New firmware can be pushed to those clients at any time, in this case the process above starts directly at step C.1.
  3. New firmware can also be pushed to the MQTT/CAN hub itself. In this case no CAN communication takes place, and the process consists only of step C.1.
  4. TODO: Clean up the deviceno 16/32 bit mess. Also, the boot announcement from the client is without nr currently.
  5. TODO: Anscheinend verhindert canboot nicht zuverlässig das Überschreiben seiner selbst. Siehe C:\Users\Hobbyraum\Documents\Atmel Studio\Atmega328P\valvebox-6406-m328pb-canboot-valvecontrol04.hex
canboot.txt · Zuletzt geändert: 2022/10/08 16:49 von sebastian