MYSBootloader 1.3 pre-release & MYSController 1.0.0beta
-
Hi all,
Here is the first public pre-release of MYSBootloader 1.3 together with MYSController 1.0.0beta for testing purposes.Download here. Thanks for your feedback.
MYSBootloader 1.3pre (1.3NS)
- requires dev branch 2.0.0 (lib 1.5 not tested)
- supports OTA FW AND serial FW updates
- no external flash needed for OTA FW updates (thus, offline update)
- bootloader commands (clear eeprom, re-assign ID, re-assign parent ID)
- communicates via assigned parent node (if found)
- 2kb bootloader size
- source code will be published to repo once final
upcoming bootloader release (1.3S):
- secure bootloader (singing and locking feature)
- 4kb bootloader size
Attached bootloader file, compiled with these settings:
- nRF24 (Channel 76, base address 0xA8A8E1FC00, data rate 250kbs)
- 115200 baud (16Mhz) or 57600 (8Mhz)
MYSBootloader 1.0.0beta
- requires dev branch 2.0.0 (lib 1.5 not tested)
- RX only mode
- GW mode: Relay traffic to server socket
- I_VERSION handling
- I_DISCOVER
- add node & sensor ID
- node persistence
- lots of improvements
Flashing MYSBootloader using Arduino IDE and USBasp:
- Add these lines to the boards.txt file in your Arduino IDE installation folder
######## settings for ext XTAL 16Mhz, EESAVE, BOD1V8, no lock
proMYSBL16.name=ATmega328 external 16Mhz with MYSBootloader
proMYSBL16.upload.tool=avrdude
proMYSBL16.upload.protocol=arduino
proMYSBL16.upload.maximum_size=30720
proMYSBL16.upload.maximum_data_size=2048
proMYSBL16.upload.speed=115200
proMYSBL16.bootloader.tool=avrdude
proMYSBL16.bootloader.low_fuses=0xFF
proMYSBL16.bootloader.high_fuses=0xD2
proMYSBL16.bootloader.extended_fuses=0x06
proMYSBL16.bootloader.unlock_bits=0x3F
proMYSBL16.bootloader.lock_bits=0x3F
proMYSBL16.bootloader.file=MySensors/MYSBootloaderV13pre.hex
proMYSBL16.build.mcu=atmega328p
proMYSBL16.build.f_cpu=16000000L
proMYSBL16.build.board=AVR_UNO
proMYSBL16.build.core=arduino
proMYSBL16.build.variant=standard######## settings for 8Mhz internal clock, EESAVE, BOD1V8, no lock
proMYSBL8.name=ATmega328 internal 8Mhz with MYSBootloader
proMYSBL8.upload.tool=avrdude
proMYSBL8.upload.protocol=arduino
proMYSBL8.upload.maximum_size=30720
proMYSBL8.upload.maximum_data_size=2048
proMYSBL8.upload.speed=57600
proMYSBL8.bootloader.tool=avrdude
proMYSBL8.bootloader.low_fuses=0xE2
proMYSBL8.bootloader.high_fuses=0xD2
proMYSBL8.bootloader.extended_fuses=0x06
proMYSBL8.bootloader.unlock_bits=0x3F
proMYSBL8.bootloader.lock_bits=0x3F
proMYSBL8.bootloader.file=MySensors/MYSBootloaderV13pre.hex
proMYSBL8.build.mcu=atmega328p
proMYSBL8.build.f_cpu=8000000L
proMYSBL8.build.board=AVR_UNO
proMYSBL8.build.core=arduino
proMYSBL8.build.variant=standard- Copy MYSBootloaderV13pre.hex (from MYSController/Bootloader folder) to the [Arduino IDE installation folder]/hardware/arduino/avr/bootloaders/MySensors/
- Restart Arduino IDE, choose under Tools | Board | ATmega328 external 16Mhz with MYSBootloader or Tools | Board | ATmega328 internal 8Mhz with MYSBootloader depending on your HW settings
- Connect USBasp to sensor node and select Tools | Programmer | USBasp and hit "Burn Bootloader"
Please use the AVR fuse calculator to retrieve the individual fuse settings. If you need to change frequency, BOD or other settings, change the fuse settings based on the fuse calculator.
OTA FW updates using MYSController:
- Start MYSController, hit config and adjust settings (COM-Port & baud or IP address:port)
- Hit connect: Connection to gateway should be established (gateway answers with gateway ready message), the node should appear and request an ID & FW.
- Right-mouse click on that node, select assign FW, choose for example TimeReporter (demo firmware included in the MYSController/Firmware folder). Then click reboot and wait until FW is uploaded and node boots.
TimeReporter firmware reports every few seconds some values such as time, millis, and voltage.
Custom firmware: compile your sketch and retrieve the generated .hex file (activate verbose mode in the Arduino IDE to get compiler messages and output path).
Copy .hex file to MYSController/Firmware folder and edit firmware_config.csv file according to the existing lines.
Hit "Refresh Repo" in MYSController and the newly copied firmware should appear in the Assign FW dropdown list, ready to be uploaded.
-
Great work! Hope to test this soon.
This is a mayor release towards the upcoming new 2.0 MySensors library.
Thanks again. -
To summarize recent discussions and open questions:
MySensors offers two OTA FW update solutions:
Dualoptiboot requires external flash: OTA FW updates are transmitted online, i.e. while the node is active. Once all FW packets are transmitted and CRC verified, the node reboots, dualoptiboot copies FW from external flash to MCU and hands over to the new sketch/FW.
Pro: Radio agnostic, online (while node processes sensor data)
Cons: Faulty FW (e.g. freezing sketch) cannot be recovered OTA => recovery via serial port necessary, external flash requiredMYSBootloader does not require external flash: OTA FW updates are transmitted offline, i.e. MYSBootloader communicates with the controller and receives new FW which is directly written to MCU, once FW is transmitted and CRC verified, MYSBootloader hands over to the new sketch/FW.
Pro: recovery OTA possible, also with a faulty/buggy sketch (if sketch freezes, watchdog resets and MYSBootloader takes over), no external flash required
Cons: Radio specific, i.e. different bootloader for RF24 and RFM69 radio (work in progess) necessary, offline (no sensor data processing possible) -
To summarize recent discussions and open questions:
MySensors offers two OTA FW update solutions:
Dualoptiboot requires external flash: OTA FW updates are transmitted online, i.e. while the node is active. Once all FW packets are transmitted and CRC verified, the node reboots, dualoptiboot copies FW from external flash to MCU and hands over to the new sketch/FW.
Pro: Radio agnostic, online (while node processes sensor data)
Cons: Faulty FW (e.g. freezing sketch) cannot be recovered OTA => recovery via serial port necessary, external flash requiredMYSBootloader does not require external flash: OTA FW updates are transmitted offline, i.e. MYSBootloader communicates with the controller and receives new FW which is directly written to MCU, once FW is transmitted and CRC verified, MYSBootloader hands over to the new sketch/FW.
Pro: recovery OTA possible, also with a faulty/buggy sketch (if sketch freezes, watchdog resets and MYSBootloader takes over), no external flash required
Cons: Radio specific, i.e. different bootloader for RF24 and RFM69 radio (work in progess) necessary, offline (no sensor data processing possible)@tekka Please post this important info in the main thread. This really makes things clear for me.
-
Actually I thought that DualOptiboot can be recovered over the air since it copies in the external flash. Thus if a faulty FW occurred because of CRC is not verified for example, then the bootloader won't copy the faulty FW to the MCU.
-
@tekka oh sorry I didn't see your post!! It seems you have done very nice improvements :) I think I have missed things...I will update the topic I started with your details.
Wow 4k bootloader with signing!
Very nice catch! I didn't thought about the faulty fw for dualoptiboot!!
So your preference goes to your little baby bootloader :) At first I choosed dualopt because I use rfm69...and because with mysbootldr if the upload fails, it would stay in bootloader and offline mode..
In other hand the faulty fw case... so to be sure I have to check carefully my sketch on breadboard before uploading!!So for the moment, I stay with dualopt for my rfm69 but will keep an eye on your rfm69 improvements ;) That said do you think dualopt will become "useless"...and I should stop to use eeprom for bootloading??? I am feeling this now..
And with 4k bootloadr, atsam becomes interesting..@ahmedadelhosni : if I understand right, faulty fw means if your code is not nice and make freeze your node, and you uploaded it, crc ok, reboot node and your bad code freeze the node..not nice usecase....
-
@tekka oh sorry I didn't see your post!! It seems you have done very nice improvements :) I think I have missed things...I will update the topic I started with your details.
Wow 4k bootloader with signing!
Very nice catch! I didn't thought about the faulty fw for dualoptiboot!!
So your preference goes to your little baby bootloader :) At first I choosed dualopt because I use rfm69...and because with mysbootldr if the upload fails, it would stay in bootloader and offline mode..
In other hand the faulty fw case... so to be sure I have to check carefully my sketch on breadboard before uploading!!So for the moment, I stay with dualopt for my rfm69 but will keep an eye on your rfm69 improvements ;) That said do you think dualopt will become "useless"...and I should stop to use eeprom for bootloading??? I am feeling this now..
And with 4k bootloadr, atsam becomes interesting..@ahmedadelhosni : if I understand right, faulty fw means if your code is not nice and make freeze your node, and you uploaded it, crc ok, reboot node and your bad code freeze the node..not nice usecase....
-
@tekka : oki ...so lot of chance I will move to your bootloader, so no need to add eeprom footprint each time, that will give more space on pcb, cool! just for curiosity/knowledge I will look at your new code and try this very sexy bootloader :)
can't wait to see your rfm69 progress! same size? and what your thought about atsam bootloadr in future? (4k can limit a little bit 328p..)
really interesting, it's an awesome work you have done. great thx for this share :) -
@tekka : oki ...so lot of chance I will move to your bootloader, so no need to add eeprom footprint each time, that will give more space on pcb, cool! just for curiosity/knowledge I will look at your new code and try this very sexy bootloader :)
can't wait to see your rfm69 progress! same size? and what your thought about atsam bootloadr in future? (4k can limit a little bit 328p..)
really interesting, it's an awesome work you have done. great thx for this share :)@scalz I think it's always a benefit to have additional eeprom or flash on your pcb for data storage. In terms of bootloader choice it totally depends on your case and preferences. MYSBootloader has some advantages over dualoptiboot, however, dualoptiboot offers more flexibility in an evolving system with e.g. changes of transmissions protocols. On top it is radio agnostic. In my current setup and during prototyping I prefer MYSBootloader over Dualoptiboot since many of my deployed nodes do not have additional external storage.
-
@tekka yep thx, I know but for some nodes I don't always need a datastorage and had the habits to add eeprom each time mainly for ota. And eeprom footprint is pretty big to place sometimes..but yes for datastorage it's cool. for the pros and cons, I agree with you, it depends of personal needs..
Have you already tried atsam boards with mysensors? I say this because I will assemble soon few atsam boards (atsamd but L family is picopower) I have designed, I will see if I'm able to port things in bootloadr but for the moment no time, too much things already in progress..in other hand, for nonpico, I'm waiting for esp32.... -
@tekka yep thx, I know but for some nodes I don't always need a datastorage and had the habits to add eeprom each time mainly for ota. And eeprom footprint is pretty big to place sometimes..but yes for datastorage it's cool. for the pros and cons, I agree with you, it depends of personal needs..
Have you already tried atsam boards with mysensors? I say this because I will assemble soon few atsam boards (atsamd but L family is picopower) I have designed, I will see if I'm able to port things in bootloadr but for the moment no time, too much things already in progress..in other hand, for nonpico, I'm waiting for esp32.... -
wow impressively cool :laughing:
thx for your kindness, now I have homeworks to do!
see you soon :) -
Sorry but I dont really get what you mean by freezy ?
You mean a code is compiled but it enters an infinite loop for example ? -
yes that's it. a bug in your code, like infinite loop, ram troubles... that should be rare depending of your code. plus generally you/I test on breadboard before sending it in prod, but that can happen and is good to know ;)
-
yes that's it. a bug in your code, like infinite loop, ram troubles... that should be rare depending of your code. plus generally you/I test on breadboard before sending it in prod, but that can happen and is good to know ;)
@scalz great.
This means that MYSBootloader can handle this problem and enter the bootloader mode even if the MCU freezes.@tekka you state that the current version can handle a freeze SW. Also if the new code is corrupted during programming by unverified CRC or whatever, it will also handle that problem and resets and wait for a new flashing order.
Is this new in this version ? I am some how sure that MYSBootloader previously had a problem handling thoses types of failures, and that's why I was going to use DualOptiboot as I read before that it can handle those failuresSorry for lots of questions but I am trying to reorganise my info.
