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:
- Clients booting for other reasons than being requested via A.2 would begin the sequence at step B.1.
- 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.
- 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.
- TODO: Clean up the deviceno 16/32 bit mess. Also, the boot announcement from the client is without nr currently.
- 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