Over the air updates
-
@tbowmo
Did some work on the OTA bootloader: combined optiboot (for uploads via IDE / avrdude) + OTA bootloader with some major modifications. Current version is stable and works for regular OTA updates :)I will post the source once I find some spare time to clean and comment it.
-
I have been thinking about OTA the last couple of days, while trying to get DualOptiboot working (using external SPI flash). If program directly, then the firmware needs to be send in a ordered way by the controler, in order for the bootloader to get things done.. What if a single package is missed?
What if we have 100 nodes, that all needs software update at the same time? Is the system able to handle that?
A part of me says, go with the direct method (that is, skipping external SPI flash) for my minimized module, but then again.. I realy want to have the added "security" of having an external flash, where I can download to, and only when checksums are correct, then I can issue a "Reload software command" to the node.
In theory, I could send the software to 100 nodes, and then when they all are ready, broadcast an "restart node" to all the affected nodes.. (future plans I know..)
Just my thoughts rambling around in my head :)
-
I have been thinking about OTA the last couple of days, while trying to get DualOptiboot working (using external SPI flash). If program directly, then the firmware needs to be send in a ordered way by the controler, in order for the bootloader to get things done.. What if a single package is missed?
What if we have 100 nodes, that all needs software update at the same time? Is the system able to handle that?
A part of me says, go with the direct method (that is, skipping external SPI flash) for my minimized module, but then again.. I realy want to have the added "security" of having an external flash, where I can download to, and only when checksums are correct, then I can issue a "Reload software command" to the node.
In theory, I could send the software to 100 nodes, and then when they all are ready, broadcast an "restart node" to all the affected nodes.. (future plans I know..)
Just my thoughts rambling around in my head :)
Yes, in the current setup, the node requests FW blocks the way they will flashed, i.e. page-wise. If one block is missing, the bootloader will re-request that block several times and reboot after a few unsuccessful attempts. The nRF24L01 has CRC on the payload and auto-retransmission of corrupt payloads (see RFInit; 15x every 150us).
As soon as the OTA update is initiated, the CRC is invalidated and the sensor remains in the bootloader until the update is successful and the CRC is valid.Updating 100 nodes simultaneously: for my understanding, the limitations are if the gateway and/or repeater nodes can handle the traffic and the connection quality). Updating sensors semi-sequentially (e.g. 5 nodes at a time) works from my experience.
Having added "security" with an external flash is certainly a nice feature (and opens other very interesting applications), but is it that important for OTA updating nodes with a down-time of a few minutes? Again, one could instruct the controller to update the nodes in a controlled fashion...
-
Sure for a temperature sensor, downtime of a couple of minutes is not an issue, but there might be other types of nodes that shouldn't have downtime.
What if we bring in the WAF? Let's say the node we want to update is the one that turns on light in the wife's walk in closet, And she is getting ready for a night out with the girlfriends :-) Then "a few" minutes downtime could be fatal to your own health :-)
-
Sure for a temperature sensor, downtime of a couple of minutes is not an issue, but there might be other types of nodes that shouldn't have downtime.
What if we bring in the WAF? Let's say the node we want to update is the one that turns on light in the wife's walk in closet, And she is getting ready for a night out with the girlfriends :-) Then "a few" minutes downtime could be fatal to your own health :-)
-
@tbowmo
...lol ;) shouldn't you be preparing for bar hopping instead of updating the sensors?
as mentioned previously, no big deal to have different updating options/sources in the bootloader, I will think about that :)@tekka said:
@tbowmo
...lol ;) shouldn't you be preparing for bar hopping instead of updating the sensors?Someone had to be at home watching the kids. And when the wife is out, we have the time to spend on fun projects, instead of doing the laundry or whatever tasks she could figure out she wanted help with :-)
-
@ToSa I finally figured out why my OTA bootloader didn't read any answers from my GW (Both on I_FIND_PARENT and I_ID_REQUEST) - The answers came to quick! First I tried hardcode a delay 125ms on the GW and it worked, so I changed the code on send write to the following and now all messages arrive. Been testing it for a couple of reboots now. I'm using 5v (at 3.3v) and 16MHz
edit; noticed it misses packages sometimes now but not close to 100% like before, more like 5% now. I'llinvestigate futher then I'm trying to upload data.static uint8_t sendAndWait(uint8_t reqType, uint8_t resType) { msg.type = reqType; for (uint8_t i = 0; i < 10; i++) { sendWrite(msg); for (uint8_t j = 0; j < 20; j++) { for (uint8_t j = 0; j < 100; j++) { uint8_t pipe; boolean avail = available(&pipe); wdt_reset(); if (avail && pipe<=6) { read(rmsg.array,pipe); if(!(mGetVersion(rmsg) == PROTOCOL_VERSION)) continue; if (rmsg.destination == nc.nodeId) { if (mGetCommand(rmsg) == C_INTERNAL) { if (rmsg.type == I_FIND_PARENT_RESPONSE) { if (rmsg.data[0] < nc.distance - 1) { nc.distance = rmsg.data[0] + 1; nc.parentNodeId = rmsg.sender; eeprom_write_byte((uint8_t*)EEPROM_PARENT_NODE_ID_ADDRESS, nc.parentNodeId); eeprom_write_byte((uint8_t*)EEPROM_DISTANCE_ADDRESS, nc.distance); } } } if ((mGetCommand(rmsg) == mGetCommand(msg)) && (rmsg.type == resType)) return 1; } } delaym(1); } } } return 0; }
