nRF5 action!

[NeverDie]

Even better, it turns out mbed solves the problem of handling multiple different interrupts, which no one here could figure out with the sandeep build. With mbed, it looks pretty simple in fact:

InterruptIn button1(P0_11);//(USER_BUTTON nRF52840 DK);
InterruptIn button2(P0_12);
InterruptIn button3(P0_24);
InterruptIn button4(P0_25);

void button1_pressed()
{
  led1 = led2 =led3 =led4 = 1;
  led1 = 0;
  
}

void button1_released()
{
  led1 = led2 =led3 =led4 = 1;
  //led1 = 0;
}

void button2_pressed()
{
  led1 = led2 =led3 =led4 = 1;
  led2 = 0;
  
}

void button2_released()
{
  led1 = led2 =led3 =led4 = 1;
  //led1 = 0;
}

void button3_pressed()
{
  led1 = led2 =led3 =led4 = 1;
  led3 = 0;
 // wait(0.1);
}

void button3_released()
{
  led1 = led2 =led3 =led4 = 1;
  //led1 = 0;
}

void button4_pressed()
{
  led1 = led2 =led3 =led4 = 1;
  led4 = 0;
  
}

void button4_released()
{
  led1 = led2 =led3 =led4 = 1;
  //led1 = 0;
}

int main() {
    led1 = led2 =led3 =led4 = 0;
    
    button1.fall(&button1_pressed);
    button1.rise(&button1_released);
    
    button2.fall(&button2_pressed);
    button2.rise(&button2_released);

    button3.fall(&button3_pressed);
    button3.rise(&button3_released);

    button4.fall(&button4_pressed);
    button4.rise(&button4_released);

   while (true) {}
}

[Nca78]

@neverdie said in nRF5 action!:

By the way, the nRF52840-DK is even easier to program thant the nRF52832-DK. When you attach it to your PC, it shows as an additional drive in your directory. Any hex file that you copy to that drive gets uploaded and programmed onto the nRF52840. Easy.

That's exactly what I'm doing with the NRF52832-DK already. How do you program yours ?

[NeverDie]

@nca78 IIRC, with nRF52832-DK I was using the arduino IDE to program it using the J-link programmer. Anyhow, that's now ancient history.

[smilvert]

@neverdie Im guessing that the BT832 dosen't have the 32.768 khz crystal but the inductors?

The datasheet says

Standby current consumption is important for battery-powered product. We suggest adding a 32.768 kHz crystal 
and 2 capacitors as shown in the upper left corner of the evaluation board schematics. The 32MHz main clock 
won’t be active at idle state to save power.

Two inductors required for DCDC converter are inside BT832 module. You can enable DCDC to lower
power consumption.

[scalz]

@NeverDie
cool. already tried it too. and i agree with you on this, arduino is fun at the beginning, but then you discover its limits. compatible with lot of things but incomplete That said, then you may end up converting some of your arduino libs/stuff to the new toolchain. On my side I like TI toolchain (free, tailored for iot with lot of nice tools, for debugging etc), not using it for nrf of course..
On other side, arduino is maybe "easier" to read for someone discovering coding.

[NeverDie]

@scalz said in nRF5 action!:

@NeverDie
cool. already tried it too. and i agree with you on this, arduino is fun at the beginning, but then you discover its limits. compatible with lot of things but incomplete That said, then you may end up converting some of your arduino libs/stuff to the new toolchain. On my side I like TI toolchain (free, tailored for iot with lot of nice tools, for debugging etc), not using it for nrf of course..
On other side, arduino is maybe "easier" to read for someone discovering coding.

Interesting! Does that mean you're using TI's' MSP430 as your primary mcu now?

[NeverDie]

@smilvert said in nRF5 action!:

@neverdie Im guessing that the BT832 dosen't have the 32.768 khz crystal but the inductors?

The datasheet says

Standby current consumption is important for battery-powered product. We suggest adding a 32.768 kHz crystal 
and 2 capacitors as shown in the upper left corner of the evaluation board schematics. The 32MHz main clock 
won’t be active at idle state to save power.

Two inductors required for DCDC converter are inside BT832 module. You can enable DCDC to lower
power consumption.

yup

[scalz]

@neverdie said in nRF5 action!:

Interesting! Does that mean you're using TI's' MSP430 as your primary mcu now?

nope, as usual I prefer the very best 430 isn't rf.
But I don't want to make OT (nrf, mysensors). just said this to say, you can usually get all power of a mcu by using the right tools like you noticed (pros&cons)

[NeverDie]

Unfortunately, the problemm with mbed is that it provides no real support for using the nRF52 radio in proprietary modes. I would have to code all of that from scratch.

[NeverDie]

Good news. I hadn't bricked the dongle after all. Yesterday I wrote some rather primitive code to send packets using the Nordic proprietary code and this morning I loaded it onto the dongle using its USB connector and USB Bootloader. I'm now receiving the packets on the nRF52840-DK, so that satisfies proof of concept. i.e. it works!

[NeverDie]

Even better news! The range is quite good. Not as awesome as my LoRa modules, but at 1mbps (I haven't yet tried 2mbps) and 8db Tx power, it easily beats the range of the nRF52832 for a comparable setup. So, to be fair, the LoRa's can use quite a bit more Tx power, and the LoRa datarate is far slower, so the nRF52840's seem likely to be quite a bit more energy efficient than LoRa for a home environment.

There is a 250Kbps speed available if using the 802.11.15 mode (which I haven't yet explored), and it should have even better range than the regular Nordic proprietary modes (of which there are only two: 1mbps, and 2mbps). IIRC, 802.11.15 can automatically handle retransmits and the like, and it's a proven standard. It likely handles a lot of the drudgery.

Then there's Thread, which is new to me but which it also supports and which is intended for home automation.

It has built in hardware acceleration for SHA256, which is pretty cool. CRC is handled by hardware too. Also, lots of crypto stuff for those who are into that.

So, although these are just early results, so far I'm liking it. In contrast, I was rather disappointed in the range of the nRF52832's (even though they were better than the range of an unamplified nRF24L01).

[alowhum]

Now if they could put it in a maker friendly package..

[NeverDie]

@alowhum I don't think Nordic ever will, though for the $10 price the dongle comes pretty close, except for the limited castellated pinout, which is inconvenient though nicely small. I'm quite sure Adafruit and Sparkfun and maybe some others will though. I think from a purely hardware point of view it pretty much blows away the Arduinos since it includes an integrated radio and is low power and has the huge flash and memory and all the other goodies.

[NeverDie]

I've started a new thread for everything related to nRF52840: https://forum.mysensors.org/topic/9717/everything-nrf52840

So, going forward, I'll mostly be posting there, unless it's for earlier products like the nRF52832 or the nRF51.

[alowhum]

This company has the cheapest arduino-ish board I've found.

It consists of a dev board..
https://www.aliexpress.com/item/NRF51822-2-4G-Wireless-Module-Wireless-Communication-Module-Bluetooth-module-zigbee-module-DMX512/32726191346.html

...and the little module you place in it:
https://www.aliexpress.com/item/NRF51822-2-4G-Wireless-Module-Wireless-Communication-Module-Bluetooth-module-zigbee-module-DMX512/32726191346.html

Total cost: about 13 euros.

[alowhum]

I just turned the BBC Micro:bit board into a MySensors repeater. No problem, went totally smooth.

The cheapest Micro-bit I've found is $18 on Aliexpress.

Lady Ada has a great PDF tutorial, full of little code snippets, to help you get started with all the onboard sensors it comes with.

[NeverDie]

@alowhum Thanks for your post. I just now looked on ebay, and there's an entire eco-system of little ad-ons for the micro bit! Lots of displays, buttons, sensors, power packs, etc.

I thought there would be a vast supply on ebay of cheap used BBC micro bits, but I didn't see any. Not sure, but maybe on the UK ebay they can be found. After all, I think a lot were given away for free initially by a magazine or something.

[alowhum]

Yes, a million were handed out to school children. And if you buy one now, one is given to a child (theoretically).

The ecosystem of attachment is indeed impressive. Parents who want their children to embrace and succeed in technology, there's quite some money to be made there.

[NeverDie]

Well, this is interesting: you can run micropython on your micro bit: https://www.amazon.com/dp/1260117588/ref=rdr_ext_tmb

[Omemanti]

Not sure if it is allowed, else I remove this post, but the nrf52832's at ebyte are for sale (50% off)the coming 2 days.cdebyte AliExpress I sure grab myself some (max 2 at a time, but last time I ordered multiple times :)) only €2,62 a piece

[NeverDie]

@omemanti said in nRF5 action!:

Not sure if it is allowed, else I remove this post, but the nrf52832's at ebyte are for sale (50% off)the coming 2 days.cdebyte AliExpress I sure grab myself some (max 2 at a time, but last time I ordered multiple times :)) only €2,62 a piece

Your post is perfectly fine, and I would even encourage it. It makes good sense to share tips like that.

The funny thing is that the 50% price is, IIRC, close to what the original price was when it was first introduced. Then the price slowly crept up from there.

[Omemanti]

@neverdie well, July 2017 they were €4,15. So they went up around 1 euro in a year. FYI the last one I bought was about 5 months ago since then they went up from version 1,1 to 1,3.
Also, the item number changed a bit (but the datasheet checks out).
It went from E73-2G4M04S to E73-2G4M04S1B, and the introduced a nrf52810 E73-2G4M04S1A with the same footprint and pinout.

[NeverDie]

@omemanti Ah, yes, you're right. It was on March 7, 2018 that they were on sale for $2.55.

Well, regardless, it's a good price.

[Nca78]

@omemanti the A version is with NRF52810, be careful.

[smilvert]

@neverdie Sorry, im a bit confused.

If im are going to use the BT832 for a battery sensor do I need to connet a 32 khz crystal like you did on the 10+ years wireless PIR Sensor (on just one set of 3 AA's!) project? But you have also written:
@neverdie said in nRF5 action!:

@alowhum IIRC, the crystal oscillator is only required by Bluetooth. For everything else, the internal resonator is sufficient.

How much more current are used if the crystal is not connected?

Can I use P00/P01 as a data pin instead of using the crystal?

[NeverDie]

You don't need the crystal. Not sure difference in current. Yes, to your last question.

[Omemanti]

@nca78 yeah I noticed that, what is the downside of the NRF52810?

[Nca78]

@omemanti said in nRF5 action!:

@nca78 yeah I noticed that, what is the downside of the NRF52810?

At least lower memory (ram and flash) and I don't know for the peripherals. Not sure if the core for nrf52832 will work flawlessly or not. Given the tiny price difference it's better to stick to nrf52832.

Low frequency crystal will make you save energy when you use Bluetooth, because it needs to wake up at precise time frames to send/receive data. Do in that case the internal oscillator is not precise enough and mcu has to wake up regularly to recalibrate it with high frequency clock.
For MySensors, it's not useful.

[Jokgi]

@nca78 There is no downside to using the nRF52810. It depends on your needs. If you can live with 192K Flash and 24K RAM and a stack that supports peripheral only (at this time) then you are good. The device can use the internal 32Khz RC osc for BTLE and there is a slight current consumption hit as the receive window will be longer. (+/- 500ppm) . No different then on the nRF52832. as stated, a 32Khz crystal will give you a tighter clock and lower current consumption.

This is a scaled down version of the nRF52832 so there are some peripherals that have been taken out or reduced. PWM for example, only one. No NFC, 1x SPI Master or Slave, (instead of 3), No I2s...... The full datasheet and product briefs are available on Nordic's website so you can A-B the features.

[Jokgi]

This post is deleted!

[NeverDie]

An amusing video, which nonetheless suggests the power of tapping into existing bluetooth devices:

nRFready Smart Remote 3 for nRF52 Series – 02:08
— Nordic Semiconductor

[Omemanti]

What are the options of getting OTA working? Is it supported? Or is it still work in progress? (If so, ia there an ETA?)

[NeverDie]

@omemanti said in nRF5 action!:

What are the options of getting OTA working? Is it supported? Or is it still work in progress? (If so, ia there an ETA?)

https://devzone.nordicsemi.com/f/nordic-q-a/38936/is-there-an-easier-to-use-ota-firmware-uploader

[NeverDie]

These are a bit cheaper than the Ebyte modules, and the breakout board is already built-in: https://www.aliexpress.com/item/NRF52832-Bluetooth-Module-BLE-4-2-Low-Power-Bluetooth-External-Antenna-IPEX-Support-Multi-Protocol/32904197412.html?spm=2114.search0104.3.102.772c16a3Fm2Lp8&ws_ab_test=searchweb0_0,searchweb201602_2_10065_10068_10130_10547_10546_10059_10884_10548_315_10545_10887_10696_100031_10084_531_10083_10103_10618_10307_449,searchweb201603_60,ppcSwitch_0&algo_expid=f8654a20-dd6e-4042-987f-5bd9eaf3c58d-15&algo_pvid=f8654a20-dd6e-4042-987f-5bd9eaf3c58d&transAbTest=ae803_4&priceBeautifyAB=0

[Jokgi]

@neverdie And it has the 32Khz crystal on it too which will reduce power consumption. And It looks like the DC/DC converter is also included?

[Toyman]

Guys, remind me pls: is CR2450 enough for the nrf52 Ebyte module acting as a Mysensors node?
Is it capable to handle tx current spikes?
Energizer datasheet states 9ma as max curent pulse. Is it sufficient?

[Toyman]

@neverdie I've setup the bootloader for my BT project and I confirm its much easier than it looks.
Can it be used for MySensors? For BT, I create a hex file in Keil and then upload it via nrftoolbox app.
Can the same procedure be used with MySensors? OTA needs Softdevice and Softdevice is not compatible with MySensors

[scalz]

@toyman said in nRF5 action!:

Guys, remind me pls: is CR2450 enough for the nrf52 Ebyte module acting as a Mysensors node?
Is it capable to handle tx current spikes?
Energizer datasheet states 9ma as max curent pulse. Is it sufficient?

yes but you need some power buffer for the spikes. So put 100uF low leakage ceramic capa close to batt holder, and you could also add one more close to your nrf5 module.

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

You already have your answer I think

[NeverDie]

@toyman said in nRF5 action!:

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

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

Let's enumerate the possible remedies:

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

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

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

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

1. Use machine.mem16

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

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

1. Use machine.mem16

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

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

[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

[Omemanti]

@maciekczwa said in nRF5 action!:

Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
debug_level: 2
0x4000
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 10000 kHz
Info : Unable to match requested speed 10000 kHz, using 4000 kHz
Info : Unable to match requested speed 10000 kHz, using 4000 kHz
Info : clock speed 4000 kHz
Info : STLINK v2 JTAG v17 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.241270
Info : nrf52.cpu: hardware has 0 breakpoints, 2 watchpoints
Error: timed out while waiting for target halted
TARGET: nrf52.cpu - Not halted
in procedure 'program'
in procedure 'reset' called at file "embedded:startup.tcl", line 478
in procedure 'ocd_bouncer'

**embedded:startup.tcl:454: Error: ** Unable to reset target ****
in procedure 'program'
in procedure 'program_error' called at file "embedded:startup.tcl", line 479
at file "embedded:startup.tcl", line 454
wybrany port szeregowy at file "embedded:startup.tcl", line 454

maybe someone else already found the solution, but it took me a while to figure it out for myself.

So for documentation sake:

Just had the exact same things with new Ebyte NRF52832 modules, ST-Link v2 couldn't erase it. (the old once did erase without a single problem )

After some digging, I found the following:
(I'm using my NRF52832-DK for it, maybe other devices work as well, just tested this one)

DK => Ebyte module
GND(detect) => GND
SWDIO => SWDIO
SWDCLK => SWCLK
VTG => 3,3V
3,3V => 3,3V
GND =>GND

you can erase the protection using nRFgo Studio

1. On the left, you can find a header named Segger, click on that.
2. then it shows that it is locked, and you can click recover.
3. after that you can erase it
4. upload a new sketch using an ST-link V2 or the DK while you are still at it.

[alowhum]

@alowhum said in nRF5 action!:

This looks like an Arduino-nano/pro-mini style device with an NRF51:

https://www.aliexpress.com/item/Nrf51822-LIS3DH-Bluetooth-Module-CJMCU-8223-Bluetooth-acceleration-module/32821873481.html

I tried uploading a simple blink sketch today. I found some code on github which suggested pin 23 and 24 are LED pins.

I got an error uploading via STM32 though.

debug_level: 2
0x4000
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 10000 kHz
Info : Unable to match requested speed 10000 kHz, using 4000 kHz
Info : Unable to match requested speed 10000 kHz, using 4000 kHz
Info : clock speed 4000 kHz
Info : STLINK v2 JTAG v17 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.233552
Warn : UNEXPECTED idcode: 0x0bb11477
Error: expected 1 of 1: 0x2ba01477
in procedure 'program'
in procedure 'init' called at file "embedded:startup.tcl", line 473
in procedure 'ocd_bouncer'
** OpenOCD init failed **
shutdown command invoked

[Toyman]

@omemanti actually, all you need is to issue the following command:
nrfjprog.exe --recover

[Omemanti]

@toyman yup, I tried that one, but all it kept saying was something like; can't find programmer.. and this method, which has a GUI, worked without incident

[Toyman]

@omemanti that's strange, I use the methos regularly and it worls fine.
Oh! Actually, sandeep's installation messes up Jlink drivers so they require reinstall for the method to work.
That's why I am using arduino nrf5 with BMP to completely separate Arduino from Jlink

[NeverDie]

FYI, I'm switching from uPython over to uLisp. It already worked on the BBC:microbit, and I just now got uLisp working on the nRF52832. Because uLisp relies on Sandeep's library, it doesn't yet support the nRF52840. However, if/when Sandeep's library does support the nRF52840, the uLisp upgrade will be fairly easy.

http://www.ulisp.com/

[Nca78]

@neverdie said in nRF5 action!:

FYI, I'm switching from uPython over to uLisp.

What is the reason for this switch ?

[NeverDie]

@nca78

1. uPython seemed to require an intimate understanding of a rather complicated build process. I kept running into build-related snags. Maybe in the future they will simplify it.
2. Its garbage collector can't handle heap fragmentation, and it appears that it never will.
3. Adding c-extensions is a rather arcane process.

In contrast, the uLisp build process is far simpler, and uLisp appears to have a proper garbage collector. Adding c-extensions is relatively easy.

[NeverDie]

For anyone interested, I posted a simple nRF52 Tx and Rx demo program written in Forth: https://github.com/rabbithat/nRF52_SimpleTxRxDemo

This code is a good starting point for beginners, because it is already working. You can easily modify the code to do whatever transmitting and receiving you want.

[NeverDie]

I just now posted a wireless Forth REPL for nRF52's on github:
https://github.com/rabbithat/nRF52_wireless_Forth_REPL

This allows you to wirelessly connect with a nRF52 remote node to update and/or interact with your code exactly the same as if the remote node was directly connected to your computer.

[smilvert]

I have recently installed an Ebyte E73 as my gateway with a DHT22. The problem is that I need to restart the gateway every 2 days and I can't figure out why. Can someone help me?

/**
   The MySensors Arduino library handles the wireless radio link and protocol
   between your home built sensors/actuators and HA controller of choice.
   The sensors forms a self healing radio network with optional repeaters. Each
   repeater and gateway builds a routing tables in EEPROM which keeps track of the
   network topology allowing messages to be routed to nodes.

   Created by Henrik Ekblad <henrik.ekblad@mysensors.org>
   Copyright (C) 2013-2017 Sensnology AB
   Full contributor list: https://github.com/mysensors/Arduino/graphs/contributors

   Documentation: http://www.mysensors.org
   Support Forum: http://forum.mysensors.org

   This program is free software; you can redistribute it and/or
   modify it under the terms of the GNU General Public License
   version 2 as published by the Free Software Foundation.

 *******************************

   REVISION HISTORY


*/

// Enable debug prints
#define MY_DEBUG

// Enable serial gateway
#define MY_GATEWAY_SERIAL



// Set blinking period
#define MY_DEFAULT_LED_BLINK_PERIOD 300

// Enable and select radio type attached
//#define MY_RADIO_NRF24
#define MY_RADIO_NRF5_ESB
//#define MY_RADIO_RFM69
//#define MY_RADIO_RFM95

#include <SPI.h>
#include <MySensors.h>
#include "DHT.h"

int switch_led = 1;
#define ledPin 11
// Set this to the pin you connected the DHT's data pin to
#define DHT_DATA_PIN 02
#define DHTTYPE DHT22   // DHT 22  (AM2302), AM2321


// Set this offset if the sensor has a permanent small offset to the real temperatures.
// In Celsius degrees (as measured by the device)
#define SENSOR_TEMP_OFFSET 0

// Sleep time between sensor updates (in milliseconds)
// Must be >1000ms for DHT22 and >2000ms for DHT11
static const uint64_t UPDATE_INTERVAL = 600000;

// Force sending an update of the temperature after n sensor reads, so a controller showing the
// timestamp of the last update doesn't show something like 3 hours in the unlikely case, that
// the value didn't change since;
// i.e. the sensor would force sending an update every UPDATE_INTERVAL*FORCE_UPDATE_N_READS [ms]
static const uint8_t FORCE_UPDATE_N_READS = 10;

#define CHILD_ID_HUM 1
#define CHILD_ID_TEMP 0

float lastTemp;
float lastHum;
uint8_t nNoUpdatesTemp;
uint8_t nNoUpdatesHum;
bool metric = true;

MyMessage msgHum(CHILD_ID_HUM, V_HUM);
MyMessage msgTemp(CHILD_ID_TEMP, V_TEMP);
DHT dht(DHT_DATA_PIN, DHTTYPE);

void setup()
{
    hwPinMode(LED_BUILTIN,OUTPUT_D0H1);

    NRF_CLOCK->INTENSET=B11;  //enable interrupts for EVENTS_HFCLKSTARTED and  EVENTS_LFCLKSTARTED
    NRF_CLOCK->TASKS_HFCLKSTART=1;  //start the high frequency crystal oscillator clock
    while (!(NRF_CLOCK->EVENTS_HFCLKSTARTED)) {} //wait until high frequency crystal oscillator clock is up to speed and working

    pinMode(PIN_LED1, OUTPUT);
    digitalWrite(PIN_LED1, HIGH);

    dht.begin(); // set data pin of DHT sensor
}

void presentation()
{
    // Send the sketch version information to the gateway and controller
    sendSketchInfo("Serial Gateway nrf52", "1.0");
    wait(500);
    // Register all sensors to gw (they will be created as child devices)
    present(CHILD_ID_TEMP, S_TEMP);
    present(CHILD_ID_HUM, S_HUM);
}

void loop()
{

    // Reading temperature or humidity takes about 250 milliseconds!
    // Sensor readings may also be up to 2 seconds 'old' (its a very slow sensor)
    float h = dht.readHumidity();
    // Read temperature as Celsius (the default)
    float t = dht.readTemperature();
    // Read temperature as Fahrenheit (isFahrenheit = true)
    float f = dht.readTemperature(true);
    Serial.print("Test print");
    // Check if any reads failed and exit early (to try again).
    if (isnan(h) || isnan(t) || isnan(f)) {
    //Serial.println("Failed to read from DHT sensor!");
    return;
    } else {
    send(msgHum.set(h, 1));
    send(msgTemp.set(t, 1));

    }

    wait(UPDATE_INTERVAL);
}

[magkudjee]

Hi every one. I'm very new in mysensors (I use bad English)
in my sketch how to setup sleep,interrupt for 3 button (์NRF51822)
thank you

#define MY_DEBUG 
#define MY_NODE_ID 4

//#define MY_RADIO_NRF24
#define MY_RADIO_NRF5_ESB

#include <SPI.h>
#include <MySensors.h>

#define CHILD_ID_SW1 1
#define CHILD_ID_SW2 2
#define CHILD_ID_SW3 3

#define BUTTON1_PIN 3
#define BUTTON2_PIN 4
#define BUTTON3_PIN 5

boolean sw1State;
boolean lastState1;
boolean tripped1 = HIGH;

boolean sw2State;
boolean lastState2;
boolean tripped2 = HIGH;

boolean sw3State;
boolean lastState3;
boolean tripped3 = HIGH;

MyMessage msg1(CHILD_ID_SW1, V_TRIPPED);
MyMessage msg2(CHILD_ID_SW2, V_TRIPPED);
MyMessage msg3(CHILD_ID_SW3, V_TRIPPED);

void presentation() 
{
  sendSketchInfo("Push Button 1", "1.0");
  
  present(CHILD_ID_SW1, S_DOOR); 
  present(CHILD_ID_SW2, S_DOOR);
  present(CHILD_ID_SW3, S_DOOR); 
}

void setup() 
{
  pinMode (BUTTON1_PIN,INPUT_PULLUP);
  pinMode (BUTTON2_PIN,INPUT_PULLUP);
  pinMode (BUTTON3_PIN,INPUT_PULLUP);

}
 
void loop() 
{ 
  sw1State = digitalRead(BUTTON1_PIN);
  if ( ( sw1State == LOW) && (lastState1 == HIGH) ) tripped1 = !tripped1;
  send(msg1.set(tripped1==HIGH ? "1" : "0"));
     lastState1 = sw1State;

  sw2State = digitalRead(BUTTON2_PIN);
  if ( ( sw2State == LOW) && (lastState2 == HIGH) ) tripped2 = !tripped2;
  send(msg2.set(tripped2==HIGH ? "1" : "0"));
     lastState2 = sw2State;

  sw3State = digitalRead(BUTTON3_PIN);
  if ( ( sw3State == LOW) && (lastState3 == HIGH) ) tripped3 = !tripped3;
  send(msg3.set(tripped3==HIGH ? "1" : "0"));
     lastState3 = sw3State;

  //sleep(digitalPinToInterrupt(BUTTON1_PIN), CHANGE, 0);    
  //sleep(INTERRUPT, CHANGE, 0);
}

[Omemanti]

@smilvert do you have some more information? like some serial output?

I had some issues with statements that uses millis(), in about 1,5 up to 2 days (much shorter the normaly I suppose) it did its rollover back to 0. This messed some waiting times for me.

[nagelc]

@magkudjee
MySensors will support 2 interrupts using sleep. I do not think it will support 3.
Use this format for the sleep call:
sleep(interrupt1, mode1, interrupt2, mode2, ms=0);
In your case: sleep(BUTTON1_PIN, CHANGE, BUTTON2_PIN, CHANGE, 0);

I don't know how to handle the 3rd interrupt.

Check the MySensors API document here: https://www.mysensors.org/download/sensor_api_20#sleeping

[smilvert]

@omemanti Well it seems to start working now... Hopefully it works Havn't restart the gateway in 2 weeks now

[mr_red]

@toyman @Omemanti

For Documentations sake:
I was having the same problems of the Ebyte E73 Module of being locked.
The ST_LinkV2 Clone Firmware are not able to recover the modules as the swd implementation is missing some direct register write capabilities.
The nfrjprog and nor openocd are working with the ST_LinkV2.

As suggested in this thread somewhere, I was able to get the modules unlocked with the Jlink clone and nrfjprog.
see also :
https://github.com/micooke/arduino-nRF5-smartwatches/blob/master/nrf52_disable_read_protection.txt

That (pirated) Firmware is working with swd and is able to recover the modules. Had to solve some dll-issues before, but got it working.
After the recovery with nrfjprog the stlink and the jlink are working as expected with openocd.

To find out if your wiring etc. is fine and it is really the locked devices you get this when starting your openocd interface.
The voltage is fine but the breakpoints are recognized.

Info : STLINK v2 JTAG v17 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.241270
Info : nrf52.cpu: hardware has 0 breakpoints, 2 watchpoints
Error: timed out while waiting for target halted
TARGET: nrf52.cpu - Not halted

It should be

Info : nrf52.cpu: hardware has 6 breakpoints, 4 watchpoints

[ileneken3]

@mr_red
I can add some of my own "documentation" on this issue. I only recently was able to program an Ebyte E73 module, and it was a long struggle. I used the NRF DK, and had help from a Nordic engineer.

• The recommended way to connect to the external device is:

Using the P20 and P1 headers, connect:
P20 VDD -> 3.3v on EBYTE 2G4M04S1B module
P20 SWDIO -> SWDIO on EBYTE 2G4M04S1B module
P20 SWDCLK -> SWDCLK on EBYTE 2G4M04S1B module
P20 VTG -> P1 VDD
P1 GND -> GND on EBYTE 2G4M04S1B module

To unlock the chip, execute:

nrfjprog -f nrf52 --recover

They also recommend using nrfjprog to program the device, because nRFgo Studio is deprecated. But I used the Studio and it worked fine. I gave Studio the .hex produced by the Arduino IDE using "Sketch" -> "Export compiled Binary".

As mentioned in the previous post, it is unlikely to unlock the board with anything but the NRF DK or a genuine J-Link. (Maybe a good fake J-Link).

Mistakes others may be able to learn from:

• Soldering the module onto a custom board can be hard. If you miss a little solder on SWDCLK or SWDIO, there is no hope. Check continuity on every pin you need!
• Make sure you don't order a NRF52810 module - only NRF52832 . You can program them, but Mysensors is not compatible. It's easy to hit the wrong link on AliExpress as they look identical.
• The NRF DK seems to deliver only 2.8V to the device. I first thought there was a problem, and tried to connect external power sources. But it seems to work powered from the DK.

[magkudjee]

@nagelc

thank you

[mr_red]

@ileneken3
It is a struggle indeed. I wanted to stay "low cost" with clone stlink and clone jlink.
As this is in preparation for a local hackspace workshop the entry level should be as low as possible.
And I suceeded to get this running for under 10€. (only one Jlink needed to unlock the modules once)

I am using platform.io and arduino, which use openocd internally. No need for nrfgo or an second programm and take the hex somewhere else.
Highly recommend platform.io for this! Flashing & Serial output are superfast, nice IDE and my dev-cycle speed up by an order of magnitude.

Question:
I am using an second device for USB-Serial convertion to get some print-msg out of the nrf52832.
Is there any way to do this over the programmer?

You can define the RX/TX pins in the nrf52832 to the pins you want.
Hardware Workaround by Neverdie: Connector Board -openhardware.io

[Toyman]

@mr_red said in nRF5 action!:

Is there any way to do this over the programmer?

Not in Arduino. In KEIL you can use RTT (pretty cool stuff, debug via SWD)
But if you just want to decrease a number of programmers, you can use Black Magic Probe, made from BluePill ($2 at Ali). It is 2-in-1 SWD and USB-UART converter on one PCB

[alowhum]

@ileneken3 @mr_red Thanks for this! Glad to hear I wasn't going crazy, but that others have had the same issue.

[Omemanti]

A quick Google pointed me to https://github.com/AndruPol/nrf52832-recover/blob/master/README.md

I do have a STM32F103C8T6 laying around. But ATM no time to play with it.

Maybe that's the €3 solution for unlocking.

[Toyman]

@omemanti said in [nRF5 action!]Maybe that's the €3 solution for unlocking.

BMP is enough to unlock. BluePill costs ca. €2 and it's easily convertable to BMP

[mr_red]

@Omemanti Good find about the BMP to recover the Ebyte module. Can you point me to an aliexpress link? "stm32" "bluepill" are not the magic chinese keywords..

[mfalkvidd]

@mr_red https://medium.com/@paramaggarwal/converting-an-stm32f103-board-to-a-black-magic-probe-c013cf2cc38c has keywords and a direct link to Ali

[alowhum]

I created a BMP, both from a cheap ST-Link and an STM32, and it didn't help me break open those eByte NRF52 units.

[mr_red]

@alowhum where did you get stuck? Whats your process?

[waspie]

@monte do you have final code now ?

[ileneken3]

@mr_red

I got to the point where the stm32loader.py runs and outputs:

Bootloader version 22
Chip id: 0x410 (STM32 Medium-density)
Write 256 bytes at 0x8000000
Write 256 bytes at 0x8000100
[..snip..]
Write 256 bytes at 0x8001900
Write 256 bytes at 0x8001A00
Read 256 bytes at 0x8000000
Read 256 bytes at 0x8000100
[..snip..]
Read 256 bytes at 0x8001900
Read 256 bytes at 0x8001A00
Verification OK

After that, you're supposed to plug in to the USB directly. I get " USB device not recognized". Zadig doesn't help. It lists it as:

"Unknown USB Device (Device Descriptor Request Failed)"

Any ideas?

Thanks.

[Toyman]

@ileneken3 have you returned the jumpers back?

[ileneken3]

@toyman
Unfortunately, yes, I have returned the jumpers to their original settings, and have even tried all 4 combinations.
I also changed computers, changed OS's, changed cables.

The board LOOKS like it was well manufactured, but I suppose a bad board is a possibility. Other than that, I can't figure out what could be wrong.

[sebi]

@d00616 said in nRF5 action!:

@Nca78 said in nRF5 Bluetooth action!:

Does that mean I have to go the long hard way with a bluepill as programmer and openocd ? Anyone has other ideas to unlock and erase the device ?

Select in to Tools menu "None" Softdevice and then "Burn Bootloader". This raises an error but the device is erased completely.

I am having the same issue trying to write on a E73 module with read/write protections. I don't have a JLink, but a ST Link-V2 and OpenOCD.
Do you know how to remove the protections on the E73 with such tools? Thanks.

[novicit]

@sebi,
A couple weeks ago I began exploring deploying E73 modules and had to remove protections. I was successful and now have a working E73 ethernet gateway. Only had ST Link-V2, so I used a "blue pill" I had in inventory to load it with Black Magic Probe. This cleared the protections.

The instructions I followed to load the BMP are step-by-step at https://github.com/TamojitSaha/STM32f103_Black-Magic-Probe

The instructions followed to clear protections with BMP also are step-by-step and worked perfect. They are at https://github.com/AndruPol/nrf52832-recover

In item #4, the program arm-none-eabi-gdb.exe seems to be part of the Arduino tool chain as I found it just by doing a search in file explorer and it was already on my win10 machine. Also, in item #4, (gdb) is the prompt that the program arm-none-eabi-gdb.exe gives. In the first line, change the '/dev/ttyACM0' to your com port. Use 'quit' to exit the program. Also, use 'mon help' to see options.

There are apparently a number of ways to 'recover' the E73, but this worked easily for me, and was step-by-step.

[ncollins]

@NeverDie Hoping you can help me with an WTNRF51822-S4AT problem where my stop recognizing interrupt events 2ish days after the last interrupt.

The buttons sleep for 24 hours, then wake up and send battery level. Even though the interrupt stops triggering, they still send battery level.

Possible some kind of timer is expiring?

Any help is appreciated.

// General settings
#define SKETCH_NAME "ThinButton"
#define SENSOR_NAME SKETCH_NAME
#define SKETCH_VERSION "1.4"

#define MY_NODE_ID 37


#define MY_BAUD_RATE 115200
//#define MY_DEBUG

#define IS_NRF51 
#define PIR_DETECTION_PIN 3
#define SHORT_WAIT 50
#define DEBOUNCE_MS 1000

volatile bool motion_change=false;

#define MY_RADIO_NRF5_ESB

#include <MySensors.h>

#define SLEEP_MS 1000 * 60 * 60 * 24

#define   CHILD_ID_VOLT 1
MyMessage msgBattery(CHILD_ID_VOLT, V_VOLTAGE);

#define CHILD_ID_BTN 2
#define BTN_PIN PIR_DETECTION_PIN
MyMessage msgBtn(CHILD_ID_BTN, V_TRIPPED);

void disableNfc() {  //only applied to nRF52

  #ifndef IS_NRF51
    //Make pins 9 and 10 usable as GPIO pins.
    NRF_NFCT->TASKS_DISABLE=1;  //disable NFC
    NRF_NVMC->CONFIG=1;  // Write enable the UICR
    NRF_UICR->NFCPINS=0; //Make pins 9 and 10 usable as GPIO pins.
    NRF_NVMC->CONFIG=0;  // Put the UICR back into read-only mode.
  #endif
}

void turnOffRadio() {
  NRF_RADIO->TASKS_DISABLE=1;
  while (!(NRF_RADIO->EVENTS_DISABLED)) {}  //until radio is confirmed disabled
}

void turnOffUarte0() {
  #ifndef IS_NRF51  
    NRF_UARTE0->TASKS_STOPRX = 1;
    NRF_UARTE0->TASKS_STOPTX = 1;
    NRF_UARTE0->TASKS_SUSPEND = 1;
    NRF_UARTE0->ENABLE=0;  //disable UART0
    while (NRF_UARTE0->ENABLE!=0) {};  //wait until UART0 is confirmed disabled.
  #endif

  #ifdef IS_NRF51
    NRF_UART0->TASKS_STOPRX = 1;
    NRF_UART0->TASKS_STOPTX = 1;
    NRF_UART0->TASKS_SUSPEND = 1;
    NRF_UART0->ENABLE=0;  //disable UART0
    while (NRF_UART0->ENABLE!=0) {};  //wait until UART0 is confirmed disabled.
  #endif
}

void turnOffAdc() {
  #ifndef IS_NRF51
    if (NRF_SAADC->ENABLE) { //if enabled, then disable the SAADC
      NRF_SAADC->TASKS_STOP=1;
      while (NRF_SAADC->EVENTS_STOPPED) {} //wait until stopping of SAADC is confirmed
      NRF_SAADC->ENABLE=0;  //disable the SAADC
      while (NRF_SAADC->ENABLE) {} //wait until the disable is confirmed
    }
  #endif
}


void turnOffHighFrequencyClock() {
    NRF_CLOCK->TASKS_HFCLKSTOP = 1;
    while ((NRF_CLOCK->HFCLKSTAT) & 0x0100) {}  //wait as long as HF clock is still running.
}


void mySleepPrepare() {  //turn-off energy drains prior to sleep
  turnOffHighFrequencyClock();
  turnOffRadio();
  turnOffUarte0();
}
 

void activateLpComp() {
  NRF_LPCOMP->PSEL=4; // monitor AIN0 (i.e. pin P0.02 on nRF52832 PIR Motion Sensor v607).
  while (!(NRF_LPCOMP->PSEL==4)) {} //wait until confirmed
  NRF_LPCOMP->REFSEL=3;  // choose 1/2 VDD as the reference voltage
  while (!(NRF_LPCOMP->REFSEL==3)) {} //wait until confirmed
  NRF_LPCOMP->ANADETECT=0;  //detect CROSS events on PIR detection pin
  while (NRF_LPCOMP->ANADETECT!=0) {} //wait until confirmed
  NRF_LPCOMP->INTENSET=B1000;  //Enable interrupt for CROSS event
  while (!(((NRF_LPCOMP->INTENSET)&B1000)==B1000)) {} //wait until confirmed
  NRF_LPCOMP->ENABLE=1;  //Enable LPCOMP
  while (!(NRF_LPCOMP->ENABLE==1)) {} //wait until confirmed
  NRF_LPCOMP->TASKS_START=1;  //start the LPCOMP
  while (!(NRF_LPCOMP->EVENTS_READY)) {}  //wait until ready
  
  NVIC_SetPriority(LPCOMP_IRQn, 15);
  NVIC_ClearPendingIRQ(LPCOMP_IRQn);
  NVIC_EnableIRQ(LPCOMP_IRQn);
}

void suspendLpComp() { //suspend getting more interrupts from LPCOMP before the first interrupt can be handled
  if ((NRF_LPCOMP->ENABLE) && (NRF_LPCOMP->EVENTS_READY)) {  //if LPCOMP is enabled
    NRF_LPCOMP->INTENCLR=B0100;  //disable interrupt from LPCOMP
    while (((NRF_LPCOMP->INTENCLR)&B0100)==B0100) {} //wait until confirmed
  }
}

void resumeLpComp() { //suspend getting interrupts from LPCOMP
  NRF_LPCOMP->INTENSET=B0100;  //Enable interrupt for UP event
  while (((NRF_LPCOMP->INTENSET)&B1000)!=B0100) {} //wait until confirmed
}
// setup
void setup() {
  hwInit();
  hwPinMode(PIR_DETECTION_PIN,INPUT);

  disableNfc();  //remove unnecessary energy drains
  turnOffAdc();  //remove unnecessary energy drains
  activateLpComp();
  motion_change=false;
}

void mySleep(uint32_t ms) {
   mySleepPrepare();  //Take steps to reduce drains on battery current prior to sleeping
   sleep(ms);
}


// presentation
void presentation() {
  sendSketchInfo(SKETCH_NAME, SKETCH_VERSION);

  present(CHILD_ID_VOLT, S_MULTIMETER, SENSOR_NAME);
  wait(SHORT_WAIT);
  present(CHILD_ID_BTN, S_MOTION, SENSOR_NAME);
  wait(SHORT_WAIT);
}

unsigned long lastTripped = millis();

// loop
void loop() {
  mySleep(SLEEP_MS);
  
  if(motion_change){
    unsigned long ms = millis();
    long timeDiff = ms - lastTripped; 
    
    if(timeDiff < 0 || timeDiff > 1000){ 
      send(msgBtn.set((uint8_t) 1));
    }
     
    NRF_LPCOMP->EVENTS_CROSS=0;
    motion_change=false;
    lastTripped = millis();
  } else {
    
    send(msgBattery.set(getInternalVoltage(),3));
  }
}

float getInternalVoltage(){
  return ((float)hwCPUVoltage())/1000.0;
}


#if __CORTEX_M == 0x04
#define NRF5_RESET_EVENT(event)                                                 \
        event = 0;                                                                   \
        (void)event
#else
#define NRF5_RESET_EVENT(event) event = 0
#endif


// This must be in one line
extern "C" { void LPCOMP_IRQHandler(void) {motion_change=true; NRF5_RESET_EVENT(NRF_LPCOMP->EVENTS_CROSS); NRF_LPCOMP->EVENTS_CROSS=0; MY_HW_RTC->CC[0]=(MY_HW_RTC->COUNTER+2);}}

[NeverDie]

@ncollins

It has been a while. I may be switching to PIC: https://forum.mysensors.org/topic/10666/anyone-ever-look-into-ezbl-aka-easy-booloader-on-a-pic

The impression I get is that you just write the new hex file into flash, flip a switch in software, and bang, you switchover to the new firmware without skipping a beat. No need to even reboot.

I think anything with the best general solution for OTA updates is a better path than doing OTA firmware bootloader one-offs for each MCU. From what I've gathered, it seems PIC may be the only one with the generalized bootloader support that I'm looking for. I haven't tried PIC before, but I'll be receiving a PIC board on Tuesday to test out this new theory. I'm gravitating toward LoRa anyway, so for that I can't leverage anything from NRF5x anyway. LoRa is the closest thing to bulletproof wireless communications that I've found so far. It just works, with fantastic range and coverage while still fitting within FCC requirements.

PICs tend to consume less energy than both atmega's and nRF5x's while sleeping, so there may be some positive trade-offs to be had there as well.

I'll miss the tight integration possible with an nRF5x. Maybe someday there will be PICs with integrated LoRa radios? MicroChip makes both separately, so it could conceivably happen. They've already done it with SAM: https://pic-microcontroller.com/microchip-new-ultra-low-power-lora-sip/

[ncollins]

@neverdie Interesting, thanks for the info

[waspie]

@ncollins I had the same problem and sort of "solved" it by having it reboot every 3 hours (or maybe it was 6).

I don't know how to use the nrf5x stuff anywhere near well enough to actually fix it but it seems to work.

[ncollins]

@waspie I was actually about to go down that route. Would you mind posting a code snippet for how you're triggering the reboot?

[waspie]

@ncollins

throw this somewhere in your code:

void reboot() {
  wdt_disable();
  wdt_enable(WDTO_15MS);
  while (1) {}
}

and then calling the reboot (in the entire loop):

void loop() {

  if (motion_change) {
    motionDetected=!motionDetected;
    if (motionDetected) {
      send(msg.set("1"));  // motion detected
    }
    else {
      digitalWrite(LED_BUILTIN,LOW);  //turn-off LED to signify motion no longer detected
      send(msg.set("0"));  // send all-clear to prepare for future detections
    }    
    
    NRF_LPCOMP->EVENTS_CROSS=0;
    motion_change=false;
  }
  else { //must be a scheduled wake-up.  Time to report voltage as a heartbeat.
    batteryVoltage=((float)hwCPUVoltage())/1000.0;  //take voltage measurement after transmission to hopefully measure lowest voltage that occurs. 
    send(msg_S_MULTIMETER_V_VOLTAGE.set(batteryVoltage,3));  //send battery voltage with 3 decimal places
    time = millis();
    if (time > 14400000 ) {
      reboot();
    }
  }
  mySleep(1200000);  //sleep for 20 minutes
}```

[ncollins]

@waspie appreciate it, thank you

[Sergio Rius]

@NeverDie Interesting. What have pulled you from nrf52 towards PICs?
Can you post a link on the board you ordered, (or one like that)? Thanks.

[NeverDie]

@sergio-rius I'm still deciding. What's holding me back from plunging into pic is that. it appears, the pics won't be able to leverage the arduino libraries. For that reason, I think I'm probably better off staying arduino compatible. In the end, it may be less effort to simply write my own OTA firmware update bootloader.