nRF5 OTA updates
-
There are discussions about OTA for nRF5 sensors. We have two variants to that:
- Use Nordics DFU mechanism.
- Implement a SoftDevice independent mechanism
Nordics DFU is ready to use for applications using the official SDK and a SoftDevice. At the moment the MySensors port doesn't support running on Chips with SoftDevice. I think this is more than a little work to implement SoftDevice Support. (NVM collision, Interrupt and RTC sharing, dependencies to non-LGPL compatible SDK...)
The SoftDevice supports updating the firmware with a smartphone and is pre-installed on most/all nRF5 chips. With this type of bootloader, it's easy to install MySensors without using programmers or special hardware. On the other side SoftDevice and bootloader requiring a lot of Flash memory, the SoftDevice reduces the usable RAM.
As I know, Nordics bootloader cannot be protected to flash other software. When a device is lost, encryption keys can be extracted.
My idea is creating a new bootloader which allows only flashing encrypted or signed code. The encryption keys can be protected with nRF5 hardware access control wich denies accessing the bootloader memory from applications. The debug interface can be disabled.
This bootloader can initially be flashed via Nordic's DFU. To do this an additional loader is required, wich runs in RAM to erase the whole Flash.
For flashing a second nRF5 or maybe nRF24 is needed. The flashing controller or additional software manages firmware delivery and encryption.
The first installation of the alternative bootloader needs a component to establish a new connection with an asymmetric key exchange. The resulting key is stored in the protected bootloader area. The initialization part can be erased after pair to the central firmware management. This keeps the boot section small.
New firmware should be flashed via a very small radio protocol, from internal flash for MySensors OTA support and via the serial port.
-
@alowhum said in nRF5 OTA updates:
Any luck? Has OTA support for NRF5 materialised?
It's not complete yet. My idea is to use mcuboot as bootloader and the MySensors OTA protocol to transfer a new firmware image. The last one is completely finished. I use the zehpyr port of mcuboot. This is working fine for NRF52 MCUs, but it depends on an memory layout of zephyr. The arduino-nrf5 port is using another memory layout.
At the moment, I can flash a new firmware image over the air, the image starts until the first interrupt routine is called. I think this can be fixed for NRF52 MCUs. Last time, I have looked into the mcuboot project, the NRF51 MCU wasn't supported.
I can't work on that in the moment, because I'm very busy with non MySensors related tasks.
-
Awesome! Glad to hear you're exploring it!
-
I just started to review the NRF5* possibilities. regarding to the code protection, are you sure that you have to implement this by your own?
what do you think about CTRL-AP - Control Access Port, APPROTECT? -
I just started to review the NRF5* possibilities. regarding to the code protection, are you sure that you have to implement this by your own?
what do you think about CTRL-AP - Control Access Port, APPROTECT?@andrew said in nRF5 OTA updates:
I just started to review the NRF5* possibilities. regarding to the code protection, are you sure that you have to implement this by your own?
what do you think about CTRL-AP - Control Access Port, APPROTECT?This is already implemented -> https://github.com/mysensors/MySensors/blob/development/hal/architecture/NRF5/MyHwNRF5.cpp#L69
Do not enable this feature until the bootloader is working. I have an NRF52 board, I can't erase after enabling the feature. I think the problem is I haven't enabled the reset pin.
I have tried to erase the MCU with ST-Link an CMSIS adapters. Maybe I have more luck with an J-Link.
-
@lorenzo said in nRF5 OTA updates:
Hi, Any news on that? If needed I can help developping.
No news from my side. Currently I have no time to work on this feature.
You can fork my Repository https://github.com/d00616/ArduinoHwNRF5 to finish the work. It's possible to send a new firmware and the image is new replaced by the bootloader but with the first interrupt the MCU is crashing. For NF52 MCUs, I think this problem is fixable by moving the IV-Pointer to the image maybe there is an problem by different memory layouts of Arduino and Zephyr (used to compile mcuboot).
