nRF5 action!

NeverDie

Can the same procedure be used with MySensors? OTA needs Softdevice and Softdevice is not compatible with MySensors

Ouch. :astonished: That does seem like a gotcha. :confounded: Thanks for pointing that out!

Let's enumerate the possible remedies: :thinking_face:

I guess theoretically the bootloader could use softdevice to handle uploads and then revert to MySensors afterward. After all, with these devices there's so much flash and memory that there's nothing which says the bootloader needs to be tiny. In that case your code would need to force a reboot, and the bootloader would need to wait a period of time to see if an OTA upload is being requested before continuing. But this is all theoretical, and I don't know enough to know whether that would be easy or difficult to make work. Far from elegant to be sure. Maybe there's a better solution than that? Admittedly, this looks like a rabbit hole I'd rather not go down.
Maybe (?) micropython is the the easier path out of this train wreck, assuming (?) it can assemble a string that it reads from OTA and then execute it (EVAL it) the way that. say, LISP, can. Then you could bypass softdevice entirely and use whatever radio communications you want. The relative ease of that might make it worth the added baggage of running an interpreter. Well, that might work for me, but for mysensors it would mean a major port to micropython, which, AFAIK, no one has yet done.
That leaves writing your own wireless bootloader, like I guess others here have done for mysensors and the atmega328p, but that doesn't sound trivial either.
Any other ideas?

I'm just thinking out loud here and above, but I'm admittedly now both stymied and flummoxed. Being wireless without the ability to do wireless updates is not good.

@scalz Does the TI platform have the same sort of issue, or does it handle OTA updates differently?

NeverDie

For instance, this buttonless approach stays in DFU mode for 30 seconds after a reset: https://thingtype.com/blog/dfu-ota-updating-an-nrf52-application-over-the-air/

I guess maybe that's the shortest path out of this dilemma.

monte

@neverdie but all those bootloaders rely on bluetooth (thus softdevice) for DFU, that means we need to write our custom bootloader which uses different transport.

NeverDie

@monte said in nRF5 action!:

@neverdie but all those bootloaders rely on bluetooth (thus softdevice) for DFU, that means we need to write our custom bootloader which uses different transport.

In a perfect world, yes. However, since that doesn't yet exist, the question is: what else, if anything, can be done today?

Nca78

@neverdie said in nRF5 action!:

In a perfect world, yes. However, since that doesn't yet exist, the question is: what else, if anything, can be done today?

Today is either use bluetooth/ant/thread (all need softdevice) or write your own OTA bootloader for legacy radio without softdevice.

NeverDie

Looks as though micropython does support the bluetooth stack for both nRF52832 and nRF52840: https://github.com/micropython/micropython/tree/master/ports/nrf

Micropython also runs on the nRF51, but apparently (judging from the BBC micro:bit), there's not also enough extra space to also support the bluetooth at the same time on the nr51.

Uhrheber

@neverdie Speaking of micropython: Adafruits fork of micropython (called circuitpython) now also supports the nRF52840. The also added the nRF52840 dongle as make target (pca10059). After compiling, you can use nRF Connect to flash the hex file to the dongle, via the stock USB DFU bootloader, so you don't need an extra programmer.

I like that dongle, it's cheap yet powerful, and it may be the smallest micropython-capable board with native USB. Native USB is nice, because in this case it has not only a serial REPL, but also a virtual drive with the code files, like the original pyboard.

NeverDie

After running through a gauntlet, I managed to get micropython running on the nRF52832-DK! I posted the firmware here: https://forum.micropython.org/viewtopic.php?f=2&t=5343&p=30756#p30756 to spare anyone else from running the same gauntlet. Just copy the firmware.hex file directly to the nRF52832-DK drive on your PC, and it will upload automatically to the DK and start running micropython. )

Toyman

@neverdie what are potential advantages of micropython?

NeverDie

@toyman OTA updates.

Toyman

@neverdie I am afraid it still relies on Softdevice

monte

@toyman no, if your code is in python. So the deal is "just" to port mysensors to python.

NeverDie

@toyman Micropython on the BBC micro:bit (which uses the nRF51822) has a Radio library that uses Nordic's proprietary radio modes and doesn't involve Bluetooth. I suppose the question is: what would be involved in getting it to run on the nRF52832 or the nRF52840. Seems like it would be substantially the same.

Faiing that, if I can directly manipulate the radio registers from miropython as I can from C, then it shouldn't be too hard to get at least minimal radio capability up and running from within micropython.

If I can get rudimentary radio communications working in micropython, then from there it should be easy to do OTA updates via REPL. I did some proof of concept to that effect on the micro:bit, but quickly ran out of memory--the micro:bit has only a total of 16K of RAM, so there's very little headroom to begin with. On the nRF52840, lack of RAM shouldn't be an issue.

NeverDie

@scalz hinted at it previously, but it looks like MyNewt OS might offer yet another way to do OTA updates. According to their posted information, it offers:

A open-source Bluetooth 5.0 stack (both Host & Controller), NimBLE, that completely replaces the proprietary SoftDevice on Nordic chipsets. (https://github.com/apache/mynewt-core/blob/master/README.md)

Apparentlly it runs on both the nRF52832 and the nRF52840.

speechsupply

@neverdie
1737 posts and counting
Spend hours reading this. Amazing journey so far.

Uhrheber

@neverdie There are three ways to manipulate registers directly from Micropython:

Use machine.mem16
Use the decorator @micropython_viper
The Viper code emitter implements integer types and pointers, allowing to access memory and registers directly.
Use the decorator @micropython.asm_thumb
Write your code in ARM assembler.

Problem: I don't know whether any of this is already implemented and works reliably in Micropython for nRF.

Toyman

@speechsupply this thread is golden. I was so empowered that was able to easily switch to nRF SDK and to start producing (semi) commercial BLE-ANT device

speechsupply

@toyman
Yea, On monday I'll order a couple of nRF52840 EVAL boards. Any suggestion regarding what to get?
Looked at both the BMD-340-EVAL and ofcourse the NRF52840-DK

NeverDie

@uhrheber said in nRF5 action!:

@neverdie There are three ways to manipulate registers directly from Micropython:

Use machine.mem16

Use the decorator @micropython_viper
The Viper code emitter implements integer types and pointers, allowing to access memory and registers directly.

Use the decorator @micropython.asm_thumb
Write your code in ARM assembler.

Problem: I don't know whether any of this is already implemented and works reliably in Micropython for nRF.

Thanks! We finally nailed it all the way down on this thread here: https://forum.micropython.org/viewtopic.php?f=12&t=5377

:smiley:

Omemanti

I see somewhat strange behaviour when using millis() for intervals.

I'm not sure it's my mistake, but one thing is that it seems that the millis rollover is around; 131.068.570 (36 hours)

When the rollover happens, it looks like it interrupts my sleep. Does that make sense?

sleep(digitalPinToInterrupt(PIR_Pin), CHANGE, LongSleep);

Debug lines => (Temp / RH - Millis)

21.44 / 61.15 - 130977952
21.43 / 61.16 - 131008158
21.42 / 61.15 - 131038364
21.44 / 61.14 - 131068570
I woke up because I saw movement at: 26576
Sleep Duration : -131042000  Im going back to sleep for 150000       
21.43 / 61.16 - 176822

20-10-2018 => its been ±36 hours laters, and he woke up again at the same moment.

18.57 / 56.88 - 131007553
18.56 / 56.86 - 131037759
18.58 / 56.85 - 131067965
I woke up because I saw movement at: 25971
Sleep duration : -131042000 => Rollover??
18.55 / 56.89 - 206423
18.53 / 56.89 - 236628
18.54 / 56.90 - 266834
18.55 / 56.89 - 297040
18.54 / 56.90 - 327246

nRF5 action!

13

11.7k

11.2k

113.0k