Over the air updates


  • Code Contributor

    @ToSa I've been working on getting OTA to work with MQTTgateway with some success.

    But I do have problem with some packages missing and I think the communication should be something like this;
    bootloader checks id and version and server said there is an update. (no change from today)
    but then:

    [bootloader] 0000 has CHK FF(just filler in first package) REQ 0000 type 01 version 01
    [server] load 0000 from hex, send addr 0000 0C9428030C9447240C9474240C947605 C7
    [bootloader] 0000 has CHK FF, REQ 0010 type 01 version 01
    [server] (checksum mismatch) send addr 0000 0C9428030C9447240C9474240C947605 C7
    [bootloader] 0000 has CHK C7, REQ 0010 type 01 version 01
    [server] load 0010 from hex send addr 0010 0C94A3050C94D0050C9480100C945003 00
    And so on.. πŸ™‚

    what do you think about this? the total package is 32bytes, mysensors header is 7bytes. and this layout would need 19 bytes from server to bootloader..
    I Have also seen some intel hex that is not in order 0010 0020 0030 etc but it could jump address. I do not think arduino ide does this but you never know..

    EDIT:
    I havn't read this one yet but I guess there is alot of good stuff in it πŸ™‚
    http://www.nordicsemi.com/eng/nordic/download_resource/10878/2/94069421


  • Code Contributor

    @JeJ @mikeones : how is your serial gateway connected? using a USB-Rs232 cable or via the GPIO pins on the RPi? Did you check the Readme.md in the NodeJsController directory?


  • Hero Member

    @Damme said:

    what do you think about this? the total package is 32bytes, mysensors header is 7bytes. and this layout would need 19 bytes from server to bootloader..

    16 bit offset, 16 data bytes, one byte checksum, right?

    I Have also seen some intel hex that is not in order 0010 0020 0030 etc but it could jump address. I do not think arduino ide does this but you never know..

    I see that your descriptions say "0010 from hex" etc, but I thought you would be fetching from a binary blob to satisfy requests from the bootloader. As in:

    Server reads the Intel hex and uses it to fill in an array of bytes. (one time, or each time a given file is requested)
    Server sends requested 16 byte chunks of that array to bootloader
    

    In that case, it doesn't matter what order the original hex lines are in, or even if they are 16 or 32 bytes wide (or less than 16 bytes at the end).


  • Code Contributor

    @Zeph true (array) and Yes, so the node can request same address twice (might be a timeout) and verify checksum on every 16byte data.


  • Code Contributor

    @Damme said:

    @ToSa I've been working on getting OTA to work with MQTTgateway with some success.

    great!

    [bootloader] 0000 has CHK FF(just filler in first package) REQ 0000 type 01 version 01
    [server] load 0000 from hex, send addr 0000 0C9428030C9447240C9474240C947605 C7
    [bootloader] 0000 has CHK FF, REQ 0010 type 01 version 01
    [server] (checksum mismatch) send addr 0000 0C9428030C9447240C9474240C947605 C7
    [bootloader] 0000 has CHK C7, REQ 0010 type 01 version 01
    [server] load 0010 from hex send addr 0010 0C94A3050C94D0050C9480100C945003 00
    And so on.. πŸ™‚

    what do you think about this? the total package is 32bytes, mysensors header is 7bytes. and this layout would need 19 bytes from server to bootloader..

    If I understand correctly you would send the CRC of the previous bloak back to the server together with the request for the next package - the server would then send the next block if the CRC is correct or resend the previous block if the CRC is not ok...
    I'm wondering how the bootloader would ever run into that situation. The package itself is checksum'ed already and wouldn't be treated as correctly received package if the checksum is incorrect. Only if the previous block was received correctly the next block is requested. If that doesn't happen within a given amount of time the same block is requested again.
    Can you explain a bit further what issues you are running into?

    @Damme said:

    I Have also seen some intel hex that is not in order 0010 0020 0030 etc but it could jump address. I do not think arduino ide does this but you never know..

    Yes, I've seen that as well - actually Codebender does that sometimes and the "HEX file loader" function on the NodeJsController would need to be adjusted to address that (I'm not reading from the .hex file when a package arrives but from a byte array in Mongo)
    Probably the best approach for this one would be to add the next address the bootloader should request to the previous package (e.g. "here is the data for 0x0000 - next request should be for 0x0010) and allow for variable block length because that's another one where Codebender sometimes uses <16 byte rows in the hex (not just at the end). The code on the bootloader side would get a little more complex as the flash is still written in pages and these might not line-up anymore with the 16byte blocks.

    @Damme said:

    I havn't read this one yet but I guess there is alot of good stuff in it πŸ™‚
    http://www.nordicsemi.com/eng/nordic/download_resource/10878/2/94069421

    That chip is a totally different animal - same RF but 8051 MCU. I'll have a look at the AppNote tomorrow.


  • Code Contributor

    @Damme said:

    @ToSa I've been looking through the ota bootloader and noticed there are alot of uint16_t wich can be replaced with uint8_t.. saves 128bytes of code. Still needs ~900bytes less until 1024 words bootloader though but is makes more space for other stuff πŸ™‚

    I'll have a look. I've taken the code from an earlier project and adjusted to MySensors - didn't review the variable types that much. I'm using CRC16 as well where CRC8 might be sufficient...

    EDIT: got it down a little from 0x0E18 to 0x0DD0 (72 bytes) changing a few loop counters from uint16 to uint8. I don't want to change type to 8bit looking at the large amount of sensors people are asking for / working on. FOr version I'm planning to keep some of these running for a long time with as little maintenance as possible. With some software improvements over time and minor version changes during development 16bit for version seems to be the better fit as well.



  • @ToSa I use a Mini-B USB cable between my PRi and my gateway.


  • Code Contributor

    @mikeones said:

    dev/ttyUSB0

    Then /dev/ttyUSB0 is correct. /dev/ttyAMA0 would only be valid for the on-board serial port on the GPIO pinheads.
    Are you running into any issues once you set the port in NodeJsGateway accordingly?



  • @ToSa I have my gateway connected via the GPIO and i have followed the steps in the Readme.md.
    I will try to use a USB-Rs232 cable and see what happens.


  • Code Contributor

    @JeJ one potential reason is that the port is already in use. I mentioned somewhere that the startup script doesn't yet stop the NodeJsController correctly. Maybe you already have a NodeJsController process running? Try "sudo killall node" and then try starting it again. To check if the port itself is working you can try to open a simple terminal (minicom etc.) and reset the gateway.


  • Hero Member

    @ToSa said:

    With some software improvements over time and minor version changes during development 16bit for version seems to be the better fit as well.

    Hmm. That seems like overkill, if I'm understanding correctly. (So maybe I am not understanding).

    What I heard was:

    Each sensactuator node has a "node type" and a "version" within that node type. Each combination of sensors and pin assignments has a unique "node type" (within a given wireless network). A node can only be OTA updated to a newer (higher) version of the same "node type" of the current firmware, and all nodes of that "node type" will be updated.

    And extra byte for "version" isn't a big deal tho.

    Will there be one or two bytes for "node type"?


  • Code Contributor

    @Zeph 16bit calculations on a 8bit mcu will always come to a price. Imo I think we should try to keep things to 8bit as much as possible. but I dont know if its possible to shred another 900bytes out of the bootloader to fit in one less size of space (1024 words instead of 2048 words). Might be if we make a mini version of mysensors/mymessage


  • Code Contributor

    @Zeph said:

    Each combination of sensors and pin assignments has a unique "node type" (within a given wireless network).

    Actually that's part of the question - as @hek mentioned there is a desire to sell MySensors hardware - at some point there might be not just generic pinhead PCBs but real fit-for-use devices. Ideally these would have a unique node type assigned not just within a given network. New firmware could be published on mysensors.org (or via codebender or...) and based on the unique (but common across networks) node type less tech-savvy people could be secured from sending a firmware that doesn't fit the hardware... I know - a LOT of "IF"s...

    @Damme
    you are right - probably not the full 900 bytes but additional space could be used for encryption etc. so every reduced byte is beneficial at this point. I'll check later how much can be saved by using CRC8 instead of CRC16.
    I'm already using a mini version of mysensors / mymessage: not using the cpp code files at all but just the headers and if you have a look at the "#ifdef __cplusplus" statements just added for that purpose, there is almost nothing left (the MyMessage class is stripped down to a struct and the MySensors class removed completely / enums and #defines should not consume space after compilation)


  • Hero Member

    @ToSa

    I'm realizing how similar the implementations of your model of updates and mine might be. This is just an early inspiration, not fully thought out.

    uint8_t   node_type_id;  // same for multiple nodes
    uint16_t version;   // loaded version for given node_type_id
    ... 
    if(new_version > version) {  // test for OTA update needed
    

    versus

    uint8_t   node_id;   // unique per node
    uint16_t  progmem_crc;  // calculated from PROGMEM
    ... 
    if(new_progmem_crc != progmem_crc) { // test for OTA update needed
    

    This might mean that I could (eventually) use a relatively minor fork of the OTA programming code to get the per-node flexibility that I seek.


  • Code Contributor

    @Zeph
    yes, that's what I meant - you might not even need any fork of the bootloader itself and just a slight adjustment on the controller end - because the nodeID is contained in the packet (not in the payload but in the header as sender address) so you have all you need for your setup


  • Hero Member

    @ToSa
    The other half is testing inequality between the computed CRC of the application firmware in PROGMEM, with the CRC of the available replacement (rather than comparing for higher version number).

    An example use case of the ability to load arbitrary new code into any given node. If I was diagnosing some kind of interference, I might temporarily replace the sensor firmware in some nodes (of varying node-type) with a custom radio test firmware, then later restore each with it's original sensor node firmware.

    Suppose we have:

     node 5, node type 17, version 2, PROGMEM CRC 0x4567  // attic
     node 6, node type 3, version 5, PROGMEM CRC 0xABCD  // crawlspace
     node 7, node type 3, version 5, PROGMAM CRC 0xABCD // living room
    

    And I want to temporarily replace the firmware in node 5 and 6, but keep 7 still running as a sensor.

    I make RF test code available on the server, with CRC 0x7E57. This is not type 17 or type 3.

    I edit the server's table of firmware assignments:

    node 5, 0x7E57
    node 6, 0x7E57
    node 7, 0xABCD  // unchanged
    

    This causes node 5 and 6 (formerly of different types) to load the test firmware when reload is triggered.

    Then when testing is done, I edit the table back:

    node 5, 0x4567   // back to its old type and version
    node 6, 0xABCD  // back to the same type and version as node 7
    node 7, 0xABCD  // still unaffected
    

    This causes the normal sensor firmware (type and version) to be loaded back in on the next reload.

    There could be more than just a CRC to identify the firmware (in order to avoid the birthday paradox), this is just an example.

    An alternate use case is loading in my Halloween firmware to the front yard nodes (but not other nodes) for a week or two, then back..

    Or an beta version of type 3, version 6, which I'd like to load on some type 3 nodes for in-situ testing (eg: in the crawlspace), but not all of the type 3 nodes because I want most of the system to continue functioning normally while I test. If the beta is bad, I may revert the test nodes to version 5; once the new version is good, I may convert all type 3 nodes to version 6.

    These are some of the reasons I'd like to be able to use OTA programming of any arbitrary firmware into any given node, without being constrained to:

      Only upgrades of the same node type
      Only upgrades to higher version numbers
      Only upgrades of all nodes of the same type or none
    

    And so that's why inequaity testing of the PROGMEM signature on a per-node basis is attractive, not just testing for a higher version number. For similar complexity, we can upgrade to a higher version number, downgrade to a different version number, or change the node type back and forth.

    The type and version dynamics (which certainly IS a common use case) can be handled on the server. For example, the server can know what type every node is (kind of a good idea anyway), and can change the node -> signature entry for every node of type 3 to the signature of the next version, and then let it proceed as above to get them all updated. But that's just one option, centrally controlled.


  • Code Contributor

    @Zeph
    from the MyOtaBootloader.c:

    if (firmwareConfigResponse->version == fc.version)
    	if (firmwareConfigResponse->blocks == fc.blocks)
    		if (firmwareConfigResponse->crc == fc.crc)
    

    so as long as you send the same version / blocks / crc back to the node as what iscurrently installed, no update is started. As soon as one of the three elements differs an update is loaded. It's completely in control of the server if (and which) firmware is bootloaded.


  • Hero Member

    @ToSa

    OK, so version is tested for != rather than for > ? Downgrading is OK?

    And CRC is used as well (and block count?) where CRC is based on what's in PROGMEM now?

    Cool.

    Then I think all that would be needed is for the server to be able to potentially feed back a different firmwareConfigResponse to each node. In my above example (which has been edited for clarity recently BTW, so re-read it), node 6 could receive a different response than node 7 (even tho they both have the same type initially). And thus nodes 5 and 6 (but not 7) could be told to load the test firmware and then later to go back to the old version. Etc.

    Is that correct?

    It would be a nice enhancement if we could query the node for the CRC (and block count?) of the current PROGMEM, just to help the server stay in sync with what's out there (eg: after a node joins the network). That could be done in the application code, so we don't even have to invoke the bootloader. Then the server could figure out which nodes need to be bootloaded and trigger just those to go into the bootloader (possibly one at a time). These two together support what I call push dynamics.


  • Code Contributor

    @Zeph I've been working on a read / write eeprom address thing in MQTT to be able to reset a node and stuff. But it seams there are more usage for it then. This might be coded into mysensors instead. (utilizing c_internal or somthing as the protocol is today)


  • Code Contributor

    @Damme said:

    @Zeph I've been working on a read / write eeprom address thing in MQTT to be able to reset a node and stuff. But it seams there are more usage for it then. This might be coded into mysensors instead. (utilizing c_internal or somthing as the protocol is today)

    Good idea - that would allow to check for current value in normal operation - not just during bootloading.

    @Zeph
    If you urgently want to have the CRC of the current firmware submitted during bootloading, we can add this as a third parameter to the FirmwareConfigRequest message. Actually I was thinking about getting rid of request/response and use the same format for both which would mean crc would be included anyways.


  • Code Contributor

    This post is deleted!

  • Code Contributor

    I deleted my last message because I though I made a big mistake..

    I've been working on a SD <-> OTA loader node, and got most of if working but got stuck on the last piece which is communication.. (i'll release it then I'm finished Ive made a small change in myotabootloader, add on line ~156 msg.destination = OTAGATEWAY; to configure custom ota address)

    I cant figure the following out:
    Just ignore contents of packages. not relevant.

    • Node: (Ota<->sd loader)

      read: 34-0-254 s=255,c=4,t=0,pt=6,l=4:FFFFFFFF
      send: 254-254-0-34 s=255,c=4,t=1,pt=8,l=4,st=ok:0100020000304200
      
    • GW:
      0;0;3;0;9;read: 34-34-0 s=255,c=3,t=7,pt=0,l=0:
      0;0;3;0;9;send: 0-0-34-34 s=255,c=3,t=8,pt=1,l=1,st=ok:0
      0;0;3;0;9;read: 34-34-0 s=255,c=3,t=7,pt=0,l=0:
      0;0;3;0;9;send: 0-0-34-34 s=255,c=3,t=8,pt=1,l=1,st=ok:0
      0;0;3;0;9;read: 34-34-254 s=255,c=4,t=0,pt=6,l=4:FFFFFFFF
      0;0;3;0;9;send: 34-0-254-254 s=255,c=4,t=0,pt=6,l=4,st=ok:FFFFFFFF
      0;0;3;0;9;read: 254-254-34 s=255,c=4,t=1,pt=6,l=8:0100020000304200
      0;0;3;0;9;send: 254-0-0-34 s=255,c=4,t=1,pt=6,l=8,st=fail:0100020000304200

    • OTA bootloader:
      Go
      <- 34,34,0,2,3,7,255,
      <- 34,34,0,2,3,7,255,
      -> 0,0,34,10,35,8,255,0,
      <- 34,34,254,34,196,0,255,255,255,255,255,

    What am I missing? package from 254 to 34 wont get delivered.
    I've also noticed that then 254 tries to send, it wont receive the next transmitted message from OTAbootloader. the next thereafter is received.


  • Code Contributor

    @Damme
    I need to better understand the setup to think about what's going on. My take from the above:

    You have three nodes:

    • Gateway (address 0)
    • SD OTA Loader Node ?!? (address 254)
    • Sensor Node (address 34)

    Is that right?


  • Code Contributor

    @ToSa Yes, And I think I figured it out.. I by mistake changed BROADCAST_ADDRESS to GATEWAY_ADDRESS in the bootloader then I was playing around. Testing the correct version now.. πŸ™‚


  • Code Contributor

    @Damme
    interesting setup πŸ‘
    to make it work with non-static addressed nodes you should probably keep the destination set to GATEWAY_ADDRESS for the REQUEST_ID call and only change afterwards.

    Never mind - looking at the line number you mentioned that's probably what you did πŸ™‚


  • Code Contributor

    @ToSa Now I remember why I changed some things in there. (broadcast to gateway)

    From the beginning I had problem getting it to talk with the GW. It only sends out
    <- 255,255,255,2,3,7,255, and gets no response, The GW tries to send but fails. (wierd..) (I dont have any relay nodes)

    This is with no modifications at all.

    0;0;3;0;9;read: 255-255-255 s=255,c=3,t=7,pt=0,l=0:
    0;0;3;0;9;send: 0-0-255-255 s=255,c=3,t=8,pt=1,l=1,st=fail:0
    0;0;3;0;9;read: 255-255-255 s=255,c=3,t=7,pt=0,l=0:
    0;0;3;0;9;send: 0-0-255-255 s=255,c=3,t=8,pt=1,l=1,st=fail:0
    other packages send out works just fine.. (To other nodes)

    and the OTA bootloader can receive other packages
    Go
    <- 255,255,255,2,3,7,255,
    -> 23,23,0,42,225,1,11,205,204,90,66,1,
    <- 255,255,255,2,3,7,255,
    <- 255,255,255,2,3,7,255,
    <- 255,255,255,2,3,7,255,

    (from a temp / hum node)

    Any ideas how to fix this?


  • Code Contributor

    @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;
      }

  • Code Contributor

    I had to put my project in the trash bin.. There is not enough RAM in the atmega328 to fit mysensors and SD-lib πŸ™‚ Tried 3 different versions..Too bad..! I could only transmit one package before SRAM got overrunned.


  • Mod

    @Damme Now do you get why I abandoned the MQTT implementation on the ATMega itself? πŸ˜‰


  • Hero Member

    @Damme said:

    I had to put my project in the trash bin.. There is not enough RAM in the atmega328 to fit mysensors and SD-lib πŸ™‚ Tried 3 different versions..Too bad..! I could only transmit one package before SRAM got overrunned.

    If you want to stay with the AVR:

    ATMega1284 based: http://lowpowerlab.com/moteino/#whatisitMEGA $20+shipping. This can add a RF69* radio, but you could instead (or also) attach a nRF24L01+

    ATMega2560 based: http://www.ebay.com/itm/121391548557 $15 shipped This has even more lines broken out than the Arduino Mega2560. (If you don't mind the larger form, Arduino Mega2560 clones start under $14 shipped).

    Or you can switch to an embedded ARM system. Teensy 3.1 for $17+ship. STM32F103 board on eBay for $7. DUE clone on eBay for $18. STM Nucleo from distributors for $11+ship (eMed programmed).

    And of course you can use the Raspberry Pi or BeagleBone Black with a faster but power hungry ARM running Linux.


  • Code Contributor

    @Damme said:

    I had to put my project in the trash bin.. There is not enough RAM in the atmega328 to fit mysensors and SD-lib πŸ™‚ Tried 3 different versions..Too bad..! I could only transmit one package before SRAM got overrunned.

    Did you try not using MySensors but the reduced nRF24 driver version I used for the bootloader itself? If the node does not need to do routing and is expected to only respond to one or two types of messages, that might be an option and is definitely smaller...


  • Hero Member

    Hi @ToSa

    Do you know if your OTA Bootloader uses more flash mem on the atmega328 vs the Optiboot bootloader?

    I have a sketch which needs Optiboot to fit and really hoping i can one day use your cool OTA stuff.

    Looking at your github it seems MyOtaBootloader.hex is 9.36k whereas Optiboot v5,0a the optiboot_atmega328.hex is 1.418k ( but there is also a optiboot_atmega328.lst file at 19.778k - I dont know enough to know if this is part of the bootloader or if its just the source???)

    Cheers,
    Greg


  • Hero Member

    OptiBoot fits in 1/2 KiB (the binary on-chip size, not the hex file).
    The OTA Bootloader is obviously larger. If you are using close to 31.5KiB on an ATMega328p, it won't fit with any bootloader larger than OptiBoot.
    .
    Make sure you use the latest compiler - 1.5.7 seems to squeeze harder (smaller binary), and I presume 1.0.6 (which has also been upgraded to a newer compiler) will also do so.

    How big does the compiler say your sketch is, at the end of a compile?


  • Hero Member

    @Zeph said:

    use the latest compiler - 1.5.7 seems to squeeze harder (smaller binary), and I presume 1.0.6 (which has also been upgraded to a newer compiler) will also do so.

    How big does the compiler say your sketch is, at the end of a compile?

    I'll check when i get home tonight.

    Very interesting about the new compiler. I'm pretty sure im using 1.0.5-r2, and i've recently begun using Atmel studio with Visual Micro addon - just soooo much better when dealing with long sketches!!!

    Cheers,
    Greg


  • Code Contributor

    @gregl the fuses determine how much space is reserved for the bootloader. I don't have the datasheet at hand but I think it varies from .5k to 4k. Optiboot is one of the smallest out there and the OTA bootloader consumes the full space because it needt to includs the (shrinked) wireless driver.


  • Hero Member

    I think the OTA bootloader which does not rely on any extra memory is a great option!

    And I think the option of having external flash may work out well too. Sending an image to be written to SPI flash might not expand the application code as much (it already has the library). Then the bootloader just has to copy from SPI to application flash. I'm thinking that might make for a smaller total footprint, since there would be no need to fit 2 nRF libraries in the 32KiB flash - a trimmed down nRF library in the boot section plus the full nRF library in application section.

    Of course, if the application gets hosed, you would not be able to do OTA bootloading and would have to physically access the node to recover, but if it's a matter of fitting or not fitting into FLASH, that might be a risk one is willing to take.


  • Mod

    @Zeph said:

    Sending an image to be written to SPI flash might not expand the application code as much (it already has the library).

    Because I am sure that Flash memory will come in handy sooner or later I have added the Winbond W25X40 to the first version of my board already :).


  • Admin

    just managed to optimize the OTA bootloader to under 2k - 2k more for sketches with OTA.


  • Code Contributor

    @tekka
    That sounds great! Can you post your code (or share a pull request)? This would either allow us to free up the remaining space or to add encryption πŸ™‚
    The only neck-breaker would be if any of the size reduction increases the risk for a bricked node that needs manual intervention (e.g. reset / power cycle etc.).


  • Admin

    what is the current status of the OTA firmware updates? Is external flash necessary at all? Is someone working on it?

    Right now I am trying to get DualOptiboot from lowpowerlabs.com to work with my board, and an external flash / eeprom. But was wondering if it would be used at all.

    Then when I got the bootloader working, I need to test firmware updates, but the road is still long and windy to get there (at the moment, only have 1 hour here, and there, to work on the hardware)


  • Admin

    @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.



  • hi, is your work on ota based on internal o external flash?


  • Admin

    @tbowmo
    internal: FW streaming via controller


  • Admin

    @tekka

    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 πŸ™‚


  • Admin

    @tbowmo

    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...


  • Admin

    @tekka

    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 πŸ™‚


  • Admin

    @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 πŸ™‚


  • Admin

    @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 πŸ™‚


  • Plugin Developer

    @Damme Is OTA working for you..I am also getting the same message from Gw.



  • I would really like to get OTA working here as it's freezing outside and I have to go there to update the software in the greenhouse control system.

    So please, can we have a 'how to' step-by-step guide to OTA? Please?

    S.


 

297
Online

8.9k
Users

9.6k
Topics

100.9k
Posts