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

@neverdie said in MySensors NRF5 Platform:

@d00616 I guess this is what you mean by Zephyr? http://docs.zephyrproject.org/boards/arm/nrf52840_pca10059/doc/nrf52840_pca10059.html?highlight=nrf52840

With Zephyr, I mean the Zephyr OS. This board definition is part of a newer Zephyr Version, I had used to compile mcuboot. This was ~7 Month ago.

If someone try to work on mcuboot compatibility. Maybe only the IV is the problem. For NRF52 the IV can be moved to the beginning of the image, but the nRF51 IV is in the mcuboot rage.

Sorry wrong wording. All P0 ports can be mapped. But to map P1 ports there is additional code required which does'n exists in the Arduino port.

@neverdie said in MySensors NRF5 Platform:

@d00616 Will everything work the same on the nRF52840?
Has anyone tried it?

Yes. At the moment, I have no time to finish my work on supporting the nrf52840. In my Repository https://github.com/d00616/ArduinoHwNRF5 you can find my last state. All 840 ports P0 (0-31) and P1 (62-64) should be usable as GPIO but there is no support using the P1 ports with any pin mapping component like UART, I2C....

The second change in my last commit is mcuboot. A bootloader compiled with Zephyr. Firmware can be upgraded OTA using MYSController with some enhancements (ask @tekka about the correct version). Firmware transmision works well but, at the moment my mcuboot port don't work. The memory layout between zephyr and arduino is different. The application cashes after start. I think it's a problem with different memory layout between Arduino and Zephyr.

For NRF52 MCUs the memory problem can be solved by moving the interrupt vector register to the IV location in the image and setting the SP register to the correct value. Maybe the starting code of ArduinoHwNRF5 is the correct position, so this mcuboot version can be used for Arduino and Zephyr Software.

If moving the SP to the correct position doesn't help, for NRF51 the Arduino linker scripts must be changed. I think there is only a small change required, but I have no idea about how to do this.

It's welcome if someone can finish this work.

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

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

@neverdie said in nRF5 Bluetooth action!:

Speaking of batteries, I found only one proper holder for holding two CR2032's in series:

There are CR2477 (560mAh) or CR2450 (950mAh) 3V cells. Maybe its's better to handle.

@nca78 said in MySensors NRF5 Platform:

Should we worry about that ?

No. There are some ports of Arduino for NRF5. At the moment MySensors is not compatible with the Primo Port, because it comes with the SoftDevice. It changes nothing for the current state.

@monte said in MySensors NRF5 Platform:

@d00616 thanks for a reply. I will evaluate my skills for this task, when I actually will get a chip to try it on. I need some really small pcb for my project, and single chip with mcu and rf with the size of nrf51 fits perfectly, but it requires quiet simple communications and full MySensors library will be overkill and hard to adapt for my needs.

If possible use the nRF52 series. There are some improvements like better radio sensivity, lower current consumption, more RAM and flash, better ADC and a better CPU. Maybe in the future there is a Firmware update OTA functionality which is easier to adapt to the NRF52 than the NRF51 platform. Another reason to use the NRF52 is, that the official Arduino NRF5 port only supports the NRF52. This port has a lot more capabilities than the arduino-nrf5 port, but MySensors is not compatible at the moment.