Continuing along the theme of one of my last projects, I built a nRF52832 into a 328p Pro Mini footprint. Made two versions: One with some edge SMA or U.Fl pads and another with a PCB trace antenna:

I wanted to start getting into using 32-bit microcontrollers (ARM Cortex varieties like nRF5x, SAMDs, STMs, etc.) for some more complex HA and other electronics projects and am trying to ease the learning curve from all my 8-bit ATMEGA experience.

Keeping the 328p pin-compatible footprint and PCB size means I can still reuse most of my other Pro Mini project boards to get going. An added bonus is the nRF52's ability to remap (almost) any pins, which will no doubt come in handy.

They’re both two layer boards and I get pretty decent range out of the PCB trace antenna - ever so slightly better RSSI than EByte’s E73-2G4M04S1B, which was surprising since I didn’t really do anything different (that I’m aware of) and their module is shielded too.

Since there’s no need for a separate nRF24 board and other associated components, like external SRAM or ATSHA, it’ll possibly save me a few $ too! Power pins next to the (remappable) I2C pins make some of the sensor modules (like SI7021) pluggable.

I also gain 16x the program memory (512K vs. 32K) and 8x the speed (64MHz vs. 8MHz) which is no small increment!

Some of the project boards I have made use of the Pro Mini 328p’s FTDI pins, so I added a few components to enable the use of an FTDI programmer with custom DFU serial bootloader.

Basically, a DTR pin toggle from the FTDI will reset the nRF52 into a state where it’ll briefly listen for a new program - similar to Adafruit’s Feather. You can also force that state for a longer period with a combination button press like Nordic and SparkFun’s development boards.

I’m unfamiliar with SWD/JTAG programming/debugging and all things GDB/OCD, so I built myself a black magic probe out of a STM32 blue pill and am going to have a play with all of that, along with VS Code and PlatformIO and probably one or two others.

MySensors nRF52 support worked out of the box (!) - so a huge thanks to all the hard work of the folks round here for getting that up and running. If there’s anything I can help with there, please let me know and if I’m able, I’ll try to take a stab at it (OTA maybe?). Like I said, I’ve got quite a steep learning curve here though.

On the low power end, I added the DCDC components Nordic recommend too and managed to get the MySensors smartSleep() current down to around 0.7uA - as per the datasheet, I think. However, I found that with a couple more code tweaks and grounding the SWDCLK, I would get into the nA region. This seems a bit out of spec to me and perhaps it’s just a measuring error, but it was repeatable and the board still happily sending data/heartbeat again each time it woke up. (It’s fluctuating around 1.6nA below - no sensors connected though, but it’s a start…)

One other project in the back of my mind is using this board as the basis for a quadcopter, but that’ll probably have to wait until the summer holidays…!

Built a 1284(p) into a 328p Pro Mini footprint. Not sure what to call it, a Pro Mini XL maybe?

I now have x4 the program memory (128K vs. 32K), x4 the EEPROM (4K vs. 1K) and x8 the SRAM (16K vs. 2K) all in a 328p Pro Mini pin-compatible (I think!) footprint of about same size.

I can also run at 20MHz vs. the usual 8MHz provided I’m prepared to run it at 4.5v and above.

Had to sacrifice a few pins and components, but might be able to put various selections back in future revisions. Nothing major (in my opinion) just components associated with the regulator really. I also went for a crystal (not installed yet, on order, LEDs too..) over a resonator - just a personal preference for when timing is critical.

And yes, those are 0402 SMDs. I actually did them by hand (!) with a microscope and a judicious amount of coffee; a fine-point iron, solder wick and flux became my best friends.

So far, I’ve had it working with nRF24s and RFM69s radios, ATSHA for personalization and external flash for FOTA. The DualOptiboot bootloader code and makefile needed a bit of tweaking, but nothing major.

I broke out the JTAG I/F but haven’t played with that yet and also added power pins next to the I2C to make some of the sensor modules (like SI7021) pluggable - see below.

I also want to play with the QTouch library support for built-in capacitive touch buttons, sliders, etc.

Why not just go with an ARM (STM32, SAMD, nRF52)?

I’m working on it! ;o)

Am not wanting to start a(nother) 8-bit vs. 32-bit discussion. I’ve got an AliExpress package of 32-bit MCUs coming (very) slowly to me. When it arrives, I’ll start experimenting and exploring - probably with the nRF52s, since those seem to be the flavor-of-the-month and very capable-looking chips...

But until then, I need more program memory!
(Among other things…)

@monte: Okay, sorry for the delay in getting back to you about this (- FWIW: UK went into another national lockdown, schools closed, so it’s been pretty crazy here the last few days...!)

I’ve dug back into my original code, done some experimenting and have tried to get down to a minimal set of steps necessary to get MySensors code to play "nicely" with a SoftDevice. Hopefully it’ll be helpful as a starting point. But note that minimal is not optimal - or even the best - see more on that below.

Caveats aside...

As far as prepping the nRF52832 goes, this HEX file will load the chip with the following MySensors-compatible regions either “in-mind” or in-place:

0x00000 to 0x00FFF -   4K MBR Region, currently up to 0xAFF.
0x01000 to 0x25FFF - 148K SoftDevice Region, currently with S132 up to 0x2514F.
0x26000 to 0x6FFFF - 272K Application Region, bootloader intelligently fills.
0x70000 to 0x70FFF -   4K VirtualPage? managed by arduino-NVM.
0x74000 to 0x7EFFF -  44K Bootloader Region, currently custom up to 0x78FCB.
0x7F000 to 0x7FFFF -   4K “EEPROM” Area? managed by arduino-NVM.

It’s best to get the bootloader to load the application code (via an FTDI) since it knows where to put it, otherwise you’re doing it manually with a JLink, etc.

The linked bootloader also expects:

UART TX on P0.11
UART RX on P0.12
USR BTN on P0.15
BLE DFU on P0.16
MCU RST on P0.21

Other optional, but useful pins are:

LED1 on P0.13
LED2 on P0.08

Once the above-linked HEX has been flashed (using JLink, BMP, etc.), you can boot the nRF52832 into a state where it is expecting a DFU over UART by grounding USR BTN (P0.15) and resetting (ground P0.21 briefly). LED1 will fade up and down slowly to confirm the new state.

Or you could do this over BLE by grounding both USR BTN and BLE DFU (P0.16) and resetting. LED1 and LED2 will fade up and down more quickly to confirm.

I’ve found the custom tools in Adafruit’s nRF52 BSP for Arduino to be pretty solid for FTDI uploading, but YMMV. Otherwise, it’s Nordic’s nRF Toolbox app.

(Note that if you do go with Adafruit’s BSP, you can call built-in functions in your Sketch code like enterSerialDfu() and enterOTADfu() to perform the same button operations as above.)

As far as prepping MySensors goes, these are (I think) the minimum files and modifications needed to make things work. In summary:

1. Either comment out the define check for NRF5 right at the bottom of MySensors/drivers/NVM/Flash.h (or define it somewhere) so that the flash driver gets compiled. This is the only file that uses that define, AFAIK.

2. If you’re using Adafruit’s nRF52 BSP (recommended), you have to make sure MySensors uses the correct pin assignment array. Quick hack is to just replace line 37 of nrf5_wiring_digital.c (MySensors/hal/architecture/NRF5/drivers) with ulPin = g_ADigitalPinMap[ulPin];

3. Finally, you will probably want to play around with the implementation of MySensors and FreeRTOS in this MyMainNRF5.cpp file (replacing the one in MySensors/hal/architecture/NRF5).

This last file is where FreeRTOS is being used to create a sort of Arduino-like structure with a loop_task() being added to the scheduler that contains both the usual setup() and loop() functions you’ll probably be familiar with from Arduino IDE land - setup() is run by MySensors inside the _begin() function.

Note that this is NOT the best or lowest power way to do this! But it is (possibly) the fastest way to get your existing MySensors sketches up and running.

Remember that this is now an RTOS running on the MCU. So ideally, you probably want to completely dispense with system ticks and move to a setup that only uses interrupts, timers, callbacks, etc. to get the lowest possible power, depending on what you’re trying to do in your Sketch. If you want a quick-and-dirty low power hack, just lower the configTICK_RATE_HZ define in FreeRTOSConfig.h (Adafruit nRF52 BSP) to something like 4 (Hz) or so - but that not the “right” way to do it...

However, that’s outside the scope of this (now, not-so) little post. If you want to dig deeper, I’d suggest familiarising yourself with FreeRTOS and reading through this low power Github issue with Adafruit’s implementation and the associated links mentioned in it - this page from FreeRTOS on Low Power Tickless Idle Support is good too. Here’s an example of an Arduino Sketch using tasks, timers and interrupts - but using Bluetooth - that illustrates a loop-less implementation.

I’ve tinkered down to the 2 or 3 µA region with MySensors using the RTC, portsense interrupts, etc. and you can, of course, go sub-µA using a custom SYSTEM OFF sleep implementation and an external nA region RTC.

I can try to put together a better MySensors integration, if folk are interested. It’ll take time though, especially now that we’re locked down for the next month…

Anyway, hope that was helpful. Any questions, I’ll do my best to respond with what I know.

(P.S. Oh, and you'll need the latest MySensors development branch to get the most stable nRF52832 radio implementation.)

Have fun!

On a related note, if anyone is trying to get the NRF2RFM69 board or similar working with the awesome Sensebender Gateway and W5100 Ethernet board, here’s what I had to do today as far as the CS and IRQ defines are concerned.

[FYI: I’m coming back to MySensors after a long hiatus and am in the process of updating (some from v1.3!) all my gateways and sensors...]

Aside from the usual radio selection, I had use the new driver and point the RFM69 NSS and IRQ pins at the nRF CS and IRQ nets. Also, if you want to, you can point the RFM69 RESET pin at the nRF CE net:

#define MY_RFM69_NEW_DRIVER
#define MY_RF69_RESET 34  // Note: Should be MY_RFM69_RST_PIN, but this didn’t work.
#define MY_RFM69_IRQ_PIN 31
#define MY_RFM69_IRQ_NUM digitalPinToInterrupt(MY_RFM69_IRQ_PIN)
#define MY_RFM69_CS_PIN 29
#define MY_DEBUG_VERBOSE_RFM69  // Note: Only if you want to check the pins, RSSI, etc.

Hope that helps someone.

@monte - Glad you found it helpful!

The bootloader I linked to is a custom (modified) one to fit the board I'm using. I remember tinkering with things like buffer sizes to make large BLE DFUs more reliable - I'd have to dig back into my notes to be sure...

But I believe Adafruit's standard nRF52 Feather should keep approximately the same memory regions - which is the "main" hurdle. I think the only other potential issue for the nRF52832 was their use of a BOOTLOADER_SETTINGS region at 0x7F000, so you'll have to check that it's not in the way of the arduino-NVM sections. On the Adafruit Bootloader side, it's all linker-related, nrf52.ld is the file I think.

Or you can, of course, modify arduino-NVM to pick it's sections somewhere else, say, underneath the bootloader, for example. Just be sure to limit how much it erases from there.

I remember nRF52840 being trickier because Adafruit had (and used) both the BOOTLOADER_SETTINGS region (this time at 0xFF000) and a BOOTLOADER_CONFIG region (at 0xFE000 - 2K, or something like that...) which they used for USB VID+PID, UF2 family, etc.

I've got a similar (custom) Adafruit-based bootloader I made for Nordic's nRF52840 Dongle that works with MySensors, if you're interested?

I couldn't get Nordic's default Dongle bootloader to play nicely with MySensors (at the time). They sign their bootloader so you can't replace it through nRF Connect without a JLink/BMP/etc. - you have to wipe the chip completely - which creates another problem. The bootloader also needs to set REGOUT0 in the UICR to 3v so you can see your LEDs and debug the thing without level-shifting (the default is 1.8v). Anyway, it does all work (eventually!) - I've currently got a Dongle serial gateway and Dongle nodes running in various places. Oh, you'll need to up the data rate too, since the 840 doesn't support the MySensors (deprecated) default of 250kbps.

Does that help at all?

What nRF52840 board(s) do you have?

@monte, @NeverDie - Took some time this weekend to take a look at this and used my previous post as something of a template; hope it helps...

Re: Nordic’s default Dongle bootloader - I never managed to get it to play nicely with MySensors and so abandoned it completely in favor of a modified version of Adafruit’s again, since I was already familiar with it from my nRF52832 work. It would have been nice if Nordic had revealed their private key to move/replace their bootloader, but I get it, I figure they’d rather you bought their DK.

This is the custom bootloader (.HEX file) my Nordic nRF52840 Dongle nodes currently use. You’ll need to completely wipe any current Dongle (or EByte E73 module) using a JLink/BMP before flashing. It has the following MySensors-compatible regions either “in-mind” or in-place:

0x00000 to 0x00FFF - 4K MBR Region, currently up to 0xAFF.
0x01000 to 0x25FFF - 148K SoftDevice Region, currently with S140 up to 0x25DE7.
0x26000 to 0xEFFFF - 807K Application Region, bootloader will intelligently fill.
0xF0000 to 0xF0FFF - 4K VirtualPage? managed by arduino-NVM.
0xF4000 to 0xFD7FF - 38K Bootloader Region, currently custom up to 0xFC01F.
0xFD800 to 0xFDFFF - 2K Bootloader Config, currently custom up to 0xFD857, 88B.
0xFF000 to 0xFFFFF - 4K “EEPROM” Area? managed by arduino-NVM.

The linked bootloader will of course expect the same pin connections as the Dongle. The important ones are probably only:

LED1_YLW_GREEN on P0.06

LED2_RGB_RED   on P0.08
LED2_RGB_GREEN on P1.09
LED2_RGB_BLUE  on P0.12

USR BTN on P1.06
BLE DFU on P1.10

MCU RST on P0.21

The bootloader supports CDC, DFU and UF2 upload modes. So the first time you flash the bootloader and reset, you can then mount it as a removable drive with UF2 support for drag-and-drop uploading of applications and/or new bootloader images, etc.

It should also appear as a usual COM port via it’s CDC descriptors, enabling FTDI-like uploading through PlatformIO/Arduino IDEs. And as before, you can perform DFUs over BLE through a manual combination button-press - more on that below...

Also as before, the bootloader shows the upload state through the LEDs, but note that on the Dongle, the LEDs are all active LOW - i.e. drive a logic zero (‘0’) to illuminate the LED(s). If you’d like a version of the bootloader where the LEDs are all active HIGH, let me know and I’ll try to dig out my old environment and compile something - you can do this yourself though…

Manually entering these upload states is similar to the nRF52832. Uploading via FTDI works as you would expect. Ground P1.06 (USR BTN) and reset (ground P0.21, MCU RST, briefly) and the nRF52840 will expect a DFU over USB either via it’s COM port or UF2 if mounted. On the Dongle, LED1 will fade up and down slowly and I think the RGB LED goes green if mounted.

For DFUs over BLE, ground P1.06 (USR BTN) and P1.10 and reset. I chose P1.10 because it’s right next to a ground pin on the Dongle and I just soldered another push switch to it. LED1 fades up and down more quickly together with the RGB LED turning blue to confirm. Uploading is via Nordic’s nRF Toolbox app and again, if you’re using Adafruit’s BSP you’ll get the built-in enterSerialDfu() and enterOTADfu() sketch functions to perform the same button operations as above.

As far as prepping MySensors goes, the same applies as above with the nRF52832, only this time you’ll need to up the data rate to 1Mbps or higher, as I mentioned earlier.

I could upload Arduino IDE and PlatformIO board variants for the Dongle if you’d like. But it’s straightforward enough to create variants for your specific board. If you’re using the Dongle, probably the most useful thing I have to hand is this code-snippet for enabling the regulator:

// Set REGOUT0 to 3V mode
// https://devzone.nordicsemi.com/nordic/short-range-guides/b/getting-started/posts/nrf52840-dongle-programming-tutorial
if ((NRF_UICR->REGOUT0 & UICR_REGOUT0_VOUT_Msk) ==
    (UICR_REGOUT0_VOUT_DEFAULT << UICR_REGOUT0_VOUT_Pos))
{
    NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Wen;
    while (NRF_NVMC->READY == NVMC_READY_READY_Busy);

    NRF_UICR->REGOUT0 = (NRF_UICR->REGOUT0 & ~((uint32_t)UICR_REGOUT0_VOUT_Msk)) |
                        (UICR_REGOUT0_VOUT_3V0 << UICR_REGOUT0_VOUT_Pos);

    NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Ren;
    while (NRF_NVMC->READY == NVMC_READY_READY_Busy);

    // System reset is needed to update UICR registers.
    NVIC_SystemReset();
}

If you stick this in an initVariant function in your variants.cpp, the Adafruit nRF52 BSP will call it as part of main.

I think that's everything - I hope it was helpful - any questions, I’ll do my best to respond a bit faster this time!

Famous last words...

That looks awesome @alexsh1!

Nicely laid out and cleanly soldered. Was that with an iron or hot air (or both)? Nice clear silk too; I like the power and “signal” symbols. Did you ever try a FOTA update with it? Or a low power/speed profile?

I see you went a bit wider and longer than the standard Pro Mini, (I’m assuming) to get at all the pins and add the extra regulator, LEDs, etc.

I was constrained by needing something that fit the same footprint for existing boards I already had, e.g. other “motherboards” I’d made similar to @sundberg84’s excellent Easy/Newbie PCB or wanting pin-compatibility for stacking boards like the ATSHA+EEPROM+Radio+ICSP one below:

I tried routing with the chip at a 45 degree angle too but couldn’t get a DRC to pass with the pads so close to the PTHs. I may try again with shorter (custom) TQFP pads...

Re: 1284p’s downsides of cost and size.

I know. I ended up justifying it to myself this way:

We can all get cheap 328p Pro Minis from Ali for around $2. The vast majority of my Pro Mini projects are battery powered, so there’s some “labor cost” to disable the power LED and remove the regulator. But regardless, I certainly can’t make myself a low(er) power Pro Mini for $2 - the OSH Park PCB alone is probably close to that.

I think the cheapest I ever got 1284p chips for was around $2.50, again from Ali. My “Pro Mini XL” PCBs were around $1.70 from OSH Park, add a sprinkling of 0402s, etc. and we’re probably at around $5.

I couldn’t find any 1284p-based boards near that price. The closest I got was Kevin’s Mini Duino, which is another lovely looking board, but doesn’t fit my need for a Pro Mini-constrained size and pin-compatibility. Essentially, I was after something close to a drop-in replacement.

So, $2+ versus $5+ for all the benefits (at least as far as I was concerned) listed above? It became a bit of a no-brainer.

And on the low power front, I profiled the MySensors library sleep command on it at around 5uA on 4.5v @ 20MHz using an external full swing, around 4uA on 3v @ 8MHz and around 3uA on 1.8v @ 1MHz Internal RC Osc:

Those numbers are certainly good enough for all my current applications - no pun intended!

But I would like to look at the 32-bit contenders as potential replacements.

I’ve seen nRF52s with 512K for around $2 on Ali, so maybe I’ll try my hand at a Pro Mini nRF52 or something similar eventually. The board above was a fun challenge, and afterall is what this is (mainly) about for me.

(Been away for a while, but saw this and thought I should chime in...)

@monte - I can confirm that this is true. I have custom nRF52832 boards with bootloaders and SoftDevices (S132) that are all currently happily running MySensors code too - I needed the bigger memory footprint AND FOTA updates, so...

As you suggest, you have to disable the SoftDevice before MySensors takes ownership of the radio otherwise there are problems. And depending on how/where you stack things, make sure that @d00616's awesome arduino-NVM layer (pseudo-EEPROM implementation) isn't going to write over anything important. I used Adafruit's FreeRTOS implementation as a starting point, but I'm not sure I fully understand what I've done in the scheduler.

I've not used the Timeslot API myself, but instead do a sort of hard-switch between the two for configuration, BLE OTA updates, etc. So for example, I have a switch in HA to put any individual node into "DFU OTA via BLE" mode - just like in the Nordic examples - then I can use their app to upload new firmware, update the SoftDevice, etc. and then reboot.

Hope that made sense.

Also @NeverDie, on the threads and meshes - I've had good success with Apache MyNewt. Their BLE Mesh implementation (using NimBLE) was relatively straightforward to work with. I made a 5x node test mesh with Publishers and Subscribers, everything provisioned using secure Network and App keys using Nordic's nRF Mesh app. Press a button on one node, all the others do something, etc. At that point, I'm not sure how useful it is to implement the MySensors protocol on top of that, but rather just choose a Publisher to act as a Gateway to your Home Automation software of choice.

Thanks for the kudos, @dbemowsk. Right back at you for your scene controllers; I’m trying to get into 3D design myself, but can’t justify the time commitment right now.

Re: Do you have these on OpenHardware.io?

No, sorry, that would require me to be far more organized than I am at present!

Maybe if there was enough interest, I could justify putting in the time to clean things up enough to publish… But it is valentines today, so any tinkering will surely be met with an icy stare if I try it tonight!

Re: Can fully functional boards be purchased somewhere? I would be interested in trying a few out if possible.

Really? I’ve never done something like that before. You do realize these are very much “alpha” right? I mean, I’ve tested the majority of the pins, but nothing like proper production hardware verification or anything. Having said that, it’s not like there’s anything complicated going on.

I managed to dig out four spares this afternoon that I’m not using from the last batch I made - how many would you like?

Three have a 1284p attached and one has the regular 1284 - I believe the only difference is the 1284 doesn’t have BOD, but I normally turn that off anyway for a (probably) miniscule power saving. I haven’t installed the crystal oscillator or reset switch yet. I don’t normally do that until I know what the use-case is. I believe I have enough spare 16MHz and 20MHz ones to fit (maybe some 8s) and some SMD reset switches too.

The only other thing would be the bootloader. I could flash the standard MySensors DualOptiboot?

So, if you (or I suppose anyone else for that matter) are interested, just shoot me a chat message via my profile and we can figure things out off-thread, as this is a bit off-topic now.

Thanks again for the interest - even if you don’t buy - made my day!

Thanks @NeverDie, I appreciate that.

Okay, well, the short answer to your question is yes, it’s a “linker directive” or rather a series of them, usually a file with the .ld extension. There’s normally a general stack/heap/etc. one called nrf_common.ld in Adafruit’s BSP, and then an architecture-specific one: nrf52.ld I think for the nRF52832 and nrf52840.ld for, well, I bet you can guess!

This architecture-specific linker directive contains the memory locations for things like the MBR, ram region for the bootloader, initialized and (shared) non-init RAM, bootloader settings/configuration, MBR parameters, etc. The bootloader itself can of course read this memory allocation/settings/configuration data and then load any new application code or indeed new bootloader code wherever it needs to be. That’s why it’s best to let the bootloader perform the FOTA, either via serial or BLE.

Now I’m guessing here, but ideally, the arduino-NVM library that sort of emulates AVR EEPROM for MySensors could just read this information too and store it’s virtual EEPROM pages around these allocations. Currently, I think it just tries to determine the top application page address from the UICR and then allocate the pages based on that. It’s been a while since I looked at the code, so it might have changed. Essentially, it’s trying to find where the bootloader starts (if there is one) and allocate some pages a bit back from there to be safe.

In theory, a large enough application could overwrite this area - that’s why it’s not the best solution as I mentioned earlier - but if you reach that point, you’ve gotten so close to the bootloader with your application code, you might be in (other) trouble anyway!

As far as a step-by-step with actual example code, demo files, etc. I’m more than happy to do it but it’ll take me some time. And would be helped if you could specify a particular board you’d like me to target (especially if I have one lying around), e.g. Nordic’s nRF52840 Dongle, Ebyte module, etc?

The other side of this is the FreeRTOS side. Would you like examples for the lowest possible power?

It seems like that’s how folk like these devices to operate. Going down around 2µA in bare System ON sleep (nRF52832) and around 300nA in bare System OFF sleep requires more involved MySensors code modifications, due to (among other things!) how FreeRTOS takes care of the power management when idling, use of the RTC(s), how it handles ISR callbacks, attaches interrupts, etc. By “bare” I mean no additional sensors, just, for example, a button or internal RTC (only in System ON) to wake it.

Does all, or at least some, of that make sense?

Thanks @NeverDie, I appreciate that.

Okay, well, the short answer to your question is yes, it’s a “linker directive” or rather a series of them, usually a file with the .ld extension. There’s normally a general stack/heap/etc. one called nrf_common.ld in Adafruit’s BSP, and then an architecture-specific one: nrf52.ld I think for the nRF52832 and nrf52840.ld for, well, I bet you can guess!

This architecture-specific linker directive contains the memory locations for things like the MBR, ram region for the bootloader, initialized and (shared) non-init RAM, bootloader settings/configuration, MBR parameters, etc. The bootloader itself can of course read this memory allocation/settings/configuration data and then load any new application code or indeed new bootloader code wherever it needs to be. That’s why it’s best to let the bootloader perform the FOTA, either via serial or BLE.

Now I’m guessing here, but ideally, the arduino-NVM library that sort of emulates AVR EEPROM for MySensors could just read this information too and store it’s virtual EEPROM pages around these allocations. Currently, I think it just tries to determine the top application page address from the UICR and then allocate the pages based on that. It’s been a while since I looked at the code, so it might have changed. Essentially, it’s trying to find where the bootloader starts (if there is one) and allocate some pages a bit back from there to be safe.

In theory, a large enough application could overwrite this area - that’s why it’s not the best solution as I mentioned earlier - but if you reach that point, you’ve gotten so close to the bootloader with your application code, you might be in (other) trouble anyway!

As far as a step-by-step with actual example code, demo files, etc. I’m more than happy to do it but it’ll take me some time. And would be helped if you could specify a particular board you’d like me to target (especially if I have one lying around), e.g. Nordic’s nRF52840 Dongle, Ebyte module, etc?

The other side of this is the FreeRTOS side. Would you like examples for the lowest possible power?

It seems like that’s how folk like these devices to operate. Going down around 2µA in bare System ON sleep (nRF52832) and around 300nA in bare System OFF sleep requires more involved MySensors code modifications, due to (among other things!) how FreeRTOS takes care of the power management when idling, use of the RTC(s), how it handles ISR callbacks, attaches interrupts, etc. By “bare” I mean no additional sensors, just, for example, a button or internal RTC (only in System ON) to wake it.

Does all, or at least some, of that make sense?

@monte, @NeverDie - Took some time this weekend to take a look at this and used my previous post as something of a template; hope it helps...

Re: Nordic’s default Dongle bootloader - I never managed to get it to play nicely with MySensors and so abandoned it completely in favor of a modified version of Adafruit’s again, since I was already familiar with it from my nRF52832 work. It would have been nice if Nordic had revealed their private key to move/replace their bootloader, but I get it, I figure they’d rather you bought their DK.

This is the custom bootloader (.HEX file) my Nordic nRF52840 Dongle nodes currently use. You’ll need to completely wipe any current Dongle (or EByte E73 module) using a JLink/BMP before flashing. It has the following MySensors-compatible regions either “in-mind” or in-place:

0x00000 to 0x00FFF - 4K MBR Region, currently up to 0xAFF.
0x01000 to 0x25FFF - 148K SoftDevice Region, currently with S140 up to 0x25DE7.
0x26000 to 0xEFFFF - 807K Application Region, bootloader will intelligently fill.
0xF0000 to 0xF0FFF - 4K VirtualPage? managed by arduino-NVM.
0xF4000 to 0xFD7FF - 38K Bootloader Region, currently custom up to 0xFC01F.
0xFD800 to 0xFDFFF - 2K Bootloader Config, currently custom up to 0xFD857, 88B.
0xFF000 to 0xFFFFF - 4K “EEPROM” Area? managed by arduino-NVM.

The linked bootloader will of course expect the same pin connections as the Dongle. The important ones are probably only:

LED1_YLW_GREEN on P0.06

LED2_RGB_RED   on P0.08
LED2_RGB_GREEN on P1.09
LED2_RGB_BLUE  on P0.12

USR BTN on P1.06
BLE DFU on P1.10

MCU RST on P0.21

The bootloader supports CDC, DFU and UF2 upload modes. So the first time you flash the bootloader and reset, you can then mount it as a removable drive with UF2 support for drag-and-drop uploading of applications and/or new bootloader images, etc.

It should also appear as a usual COM port via it’s CDC descriptors, enabling FTDI-like uploading through PlatformIO/Arduino IDEs. And as before, you can perform DFUs over BLE through a manual combination button-press - more on that below...

Also as before, the bootloader shows the upload state through the LEDs, but note that on the Dongle, the LEDs are all active LOW - i.e. drive a logic zero (‘0’) to illuminate the LED(s). If you’d like a version of the bootloader where the LEDs are all active HIGH, let me know and I’ll try to dig out my old environment and compile something - you can do this yourself though…

Manually entering these upload states is similar to the nRF52832. Uploading via FTDI works as you would expect. Ground P1.06 (USR BTN) and reset (ground P0.21, MCU RST, briefly) and the nRF52840 will expect a DFU over USB either via it’s COM port or UF2 if mounted. On the Dongle, LED1 will fade up and down slowly and I think the RGB LED goes green if mounted.

For DFUs over BLE, ground P1.06 (USR BTN) and P1.10 and reset. I chose P1.10 because it’s right next to a ground pin on the Dongle and I just soldered another push switch to it. LED1 fades up and down more quickly together with the RGB LED turning blue to confirm. Uploading is via Nordic’s nRF Toolbox app and again, if you’re using Adafruit’s BSP you’ll get the built-in enterSerialDfu() and enterOTADfu() sketch functions to perform the same button operations as above.

As far as prepping MySensors goes, the same applies as above with the nRF52832, only this time you’ll need to up the data rate to 1Mbps or higher, as I mentioned earlier.

I could upload Arduino IDE and PlatformIO board variants for the Dongle if you’d like. But it’s straightforward enough to create variants for your specific board. If you’re using the Dongle, probably the most useful thing I have to hand is this code-snippet for enabling the regulator:

// Set REGOUT0 to 3V mode
// https://devzone.nordicsemi.com/nordic/short-range-guides/b/getting-started/posts/nrf52840-dongle-programming-tutorial
if ((NRF_UICR->REGOUT0 & UICR_REGOUT0_VOUT_Msk) ==
    (UICR_REGOUT0_VOUT_DEFAULT << UICR_REGOUT0_VOUT_Pos))
{
    NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Wen;
    while (NRF_NVMC->READY == NVMC_READY_READY_Busy);

    NRF_UICR->REGOUT0 = (NRF_UICR->REGOUT0 & ~((uint32_t)UICR_REGOUT0_VOUT_Msk)) |
                        (UICR_REGOUT0_VOUT_3V0 << UICR_REGOUT0_VOUT_Pos);

    NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Ren;
    while (NRF_NVMC->READY == NVMC_READY_READY_Busy);

    // System reset is needed to update UICR registers.
    NVIC_SystemReset();
}

If you stick this in an initVariant function in your variants.cpp, the Adafruit nRF52 BSP will call it as part of main.

I think that's everything - I hope it was helpful - any questions, I’ll do my best to respond a bit faster this time!

Famous last words...

@monte - Glad you found it helpful!

The bootloader I linked to is a custom (modified) one to fit the board I'm using. I remember tinkering with things like buffer sizes to make large BLE DFUs more reliable - I'd have to dig back into my notes to be sure...

But I believe Adafruit's standard nRF52 Feather should keep approximately the same memory regions - which is the "main" hurdle. I think the only other potential issue for the nRF52832 was their use of a BOOTLOADER_SETTINGS region at 0x7F000, so you'll have to check that it's not in the way of the arduino-NVM sections. On the Adafruit Bootloader side, it's all linker-related, nrf52.ld is the file I think.

Or you can, of course, modify arduino-NVM to pick it's sections somewhere else, say, underneath the bootloader, for example. Just be sure to limit how much it erases from there.

I remember nRF52840 being trickier because Adafruit had (and used) both the BOOTLOADER_SETTINGS region (this time at 0xFF000) and a BOOTLOADER_CONFIG region (at 0xFE000 - 2K, or something like that...) which they used for USB VID+PID, UF2 family, etc.

I've got a similar (custom) Adafruit-based bootloader I made for Nordic's nRF52840 Dongle that works with MySensors, if you're interested?

I couldn't get Nordic's default Dongle bootloader to play nicely with MySensors (at the time). They sign their bootloader so you can't replace it through nRF Connect without a JLink/BMP/etc. - you have to wipe the chip completely - which creates another problem. The bootloader also needs to set REGOUT0 in the UICR to 3v so you can see your LEDs and debug the thing without level-shifting (the default is 1.8v). Anyway, it does all work (eventually!) - I've currently got a Dongle serial gateway and Dongle nodes running in various places. Oh, you'll need to up the data rate too, since the 840 doesn't support the MySensors (deprecated) default of 250kbps.

Does that help at all?

What nRF52840 board(s) do you have?

@monte: Okay, sorry for the delay in getting back to you about this (- FWIW: UK went into another national lockdown, schools closed, so it’s been pretty crazy here the last few days...!)

I’ve dug back into my original code, done some experimenting and have tried to get down to a minimal set of steps necessary to get MySensors code to play "nicely" with a SoftDevice. Hopefully it’ll be helpful as a starting point. But note that minimal is not optimal - or even the best - see more on that below.

Caveats aside...

As far as prepping the nRF52832 goes, this HEX file will load the chip with the following MySensors-compatible regions either “in-mind” or in-place:

0x00000 to 0x00FFF -   4K MBR Region, currently up to 0xAFF.
0x01000 to 0x25FFF - 148K SoftDevice Region, currently with S132 up to 0x2514F.
0x26000 to 0x6FFFF - 272K Application Region, bootloader intelligently fills.
0x70000 to 0x70FFF -   4K VirtualPage? managed by arduino-NVM.
0x74000 to 0x7EFFF -  44K Bootloader Region, currently custom up to 0x78FCB.
0x7F000 to 0x7FFFF -   4K “EEPROM” Area? managed by arduino-NVM.

It’s best to get the bootloader to load the application code (via an FTDI) since it knows where to put it, otherwise you’re doing it manually with a JLink, etc.

The linked bootloader also expects:

UART TX on P0.11
UART RX on P0.12
USR BTN on P0.15
BLE DFU on P0.16
MCU RST on P0.21

Other optional, but useful pins are:

LED1 on P0.13
LED2 on P0.08

Once the above-linked HEX has been flashed (using JLink, BMP, etc.), you can boot the nRF52832 into a state where it is expecting a DFU over UART by grounding USR BTN (P0.15) and resetting (ground P0.21 briefly). LED1 will fade up and down slowly to confirm the new state.

Or you could do this over BLE by grounding both USR BTN and BLE DFU (P0.16) and resetting. LED1 and LED2 will fade up and down more quickly to confirm.

I’ve found the custom tools in Adafruit’s nRF52 BSP for Arduino to be pretty solid for FTDI uploading, but YMMV. Otherwise, it’s Nordic’s nRF Toolbox app.

(Note that if you do go with Adafruit’s BSP, you can call built-in functions in your Sketch code like enterSerialDfu() and enterOTADfu() to perform the same button operations as above.)

As far as prepping MySensors goes, these are (I think) the minimum files and modifications needed to make things work. In summary:

1. Either comment out the define check for NRF5 right at the bottom of MySensors/drivers/NVM/Flash.h (or define it somewhere) so that the flash driver gets compiled. This is the only file that uses that define, AFAIK.

2. If you’re using Adafruit’s nRF52 BSP (recommended), you have to make sure MySensors uses the correct pin assignment array. Quick hack is to just replace line 37 of nrf5_wiring_digital.c (MySensors/hal/architecture/NRF5/drivers) with ulPin = g_ADigitalPinMap[ulPin];

3. Finally, you will probably want to play around with the implementation of MySensors and FreeRTOS in this MyMainNRF5.cpp file (replacing the one in MySensors/hal/architecture/NRF5).

This last file is where FreeRTOS is being used to create a sort of Arduino-like structure with a loop_task() being added to the scheduler that contains both the usual setup() and loop() functions you’ll probably be familiar with from Arduino IDE land - setup() is run by MySensors inside the _begin() function.

Note that this is NOT the best or lowest power way to do this! But it is (possibly) the fastest way to get your existing MySensors sketches up and running.

Remember that this is now an RTOS running on the MCU. So ideally, you probably want to completely dispense with system ticks and move to a setup that only uses interrupts, timers, callbacks, etc. to get the lowest possible power, depending on what you’re trying to do in your Sketch. If you want a quick-and-dirty low power hack, just lower the configTICK_RATE_HZ define in FreeRTOSConfig.h (Adafruit nRF52 BSP) to something like 4 (Hz) or so - but that not the “right” way to do it...

However, that’s outside the scope of this (now, not-so) little post. If you want to dig deeper, I’d suggest familiarising yourself with FreeRTOS and reading through this low power Github issue with Adafruit’s implementation and the associated links mentioned in it - this page from FreeRTOS on Low Power Tickless Idle Support is good too. Here’s an example of an Arduino Sketch using tasks, timers and interrupts - but using Bluetooth - that illustrates a loop-less implementation.

I’ve tinkered down to the 2 or 3 µA region with MySensors using the RTC, portsense interrupts, etc. and you can, of course, go sub-µA using a custom SYSTEM OFF sleep implementation and an external nA region RTC.

I can try to put together a better MySensors integration, if folk are interested. It’ll take time though, especially now that we’re locked down for the next month…

Anyway, hope that was helpful. Any questions, I’ll do my best to respond with what I know.

(P.S. Oh, and you'll need the latest MySensors development branch to get the most stable nRF52832 radio implementation.)

Have fun!

@monte - No, not quite. I'll have to dig back into my local codebase. I use PlatformIO, but I remember having to modify one or more arduino-NVM files to make them compile for Adafruit's nRF52 BSP, something else with how the digital pins were defined (probably minor) elsewhere and of course update MyMainNRF5.cpp to work with their FreeRTOS scheduler. I remember that last part being a bit painful to debug - even with a JLink - but the nodes are pretty solid now.

I can do a diff later this evening if you're interested...?

Yes, Adafruit went with using an RTOS to manage their SoftDevice interfacing. I suppose there are pros/cons to that, but their support was definitely a pro! The useful part is being able to disable it cleanly (!) and then being able to jump back into it when it's safe to do so. FOTA updates with Nordic's app are always solid.

And yes, I've got a custom version of their bootloader running on my boards. Nothing fancy - different pins, buttons, LEDs, etc. I might have modified one or two other bits here and there, but their base should be a good enough starting point.

What boards are you using? And how are you programming them?

(Been away for a while, but saw this and thought I should chime in...)

@monte - I can confirm that this is true. I have custom nRF52832 boards with bootloaders and SoftDevices (S132) that are all currently happily running MySensors code too - I needed the bigger memory footprint AND FOTA updates, so...

As you suggest, you have to disable the SoftDevice before MySensors takes ownership of the radio otherwise there are problems. And depending on how/where you stack things, make sure that @d00616's awesome arduino-NVM layer (pseudo-EEPROM implementation) isn't going to write over anything important. I used Adafruit's FreeRTOS implementation as a starting point, but I'm not sure I fully understand what I've done in the scheduler.

I've not used the Timeslot API myself, but instead do a sort of hard-switch between the two for configuration, BLE OTA updates, etc. So for example, I have a switch in HA to put any individual node into "DFU OTA via BLE" mode - just like in the Nordic examples - then I can use their app to upload new firmware, update the SoftDevice, etc. and then reboot.

Hope that made sense.

Also @NeverDie, on the threads and meshes - I've had good success with Apache MyNewt. Their BLE Mesh implementation (using NimBLE) was relatively straightforward to work with. I made a 5x node test mesh with Publishers and Subscribers, everything provisioned using secure Network and App keys using Nordic's nRF Mesh app. Press a button on one node, all the others do something, etc. At that point, I'm not sure how useful it is to implement the MySensors protocol on top of that, but rather just choose a Publisher to act as a Gateway to your Home Automation software of choice.

Thanks @berkseo!

Have been enjoying your work with nRF52 designs.

Also on my list is trying the built-in capacitive touch capabilities of the chip.

I can @ you if I get anywhere with it - might come in handy for your capacitive touch glass mini switch to save you a few components?

Very nice @Fanfan!

Love the power protections - those would have saved me a few nRF24s in the past!

How have you found the ceramic antennas?

I’ve been wondering whether to add pads to mine for experimenting...

@monte Re: FTDI Boards & Bootloaders.

I didn’t write the bootloader myself from scratch, but modified and combined various elements from Nordic’s SDK v11 example, SparkFun’s development version and Adafruit’s Feather version.

It was quite a nice learning experience of hacking in bootloader land and dealing with event-driven architectures without any low level debugging skills (yet!) - that’s why I’m now trying to get into SWD/JTAG debugging to make things like this easier.

I certainly don’t understand everything that’s going on, but “loosely” from what I can figure out, it uses Nordic’s proprietary SoftDevice (S132) combined with some custom bootloader code to boot into a predefined state, where it’ll wait for new “image” either over a serial or bluetooth connection.

The new “image” can be either your regular sketch-type code (referred to as the “application”), a new SoftDevice (S212, S332, etc.) and/or even a new bootloader.

Once the new “image” is received and validated by the (existing) bootloader, it is copied to replace the existing “image” parts where necessary and the chip is reset.

Nordic’s pc-nrfutil command line utility handles interfacing with any standard FTDI board over a COM port (mine is an old SparkFun, but any should work) to perform the upload.

In SDK11, there isn’t much in the way of safeguards, but in SDK15 there are things like cryptographic signing, custom initialization packets and protocol buffers, etc.

I did have to make one tweak to the nrfutil Python code, to make it wait a little longer after opening the COM port before sending the DFU initialization packet. This might be unnecessary with optimized bootloader code, I don’t know, since the nRF52832 boots pretty quickly.

I could go on, but I’m still learning myself, and so if you or anyone else has any other questions, comments, suggestions, etc., perhaps we better move them to a new discussion thread? (Just tag me in so I see it…)

Thanks for your interest though!

@nagelc Thanks! The clip on programmer is one-part Adafruit’s FTDI “Fiddy” from here, and one-part SparkFun’s old (retired?) 3.3 or 5v selectable FTDI programmer with a custom 3D printed enclosure.

I plan to modify the “Fiddy” design a bit as there were some elements of it that I’ve found a bit frustrating. However, YMMV. Gotta love pogo pins for programming though…

Re: Board envy. Really? Well, if you like, I could do what I did on my last project - which was selling the leftovers. At the moment, I always make more than I need, for testing and some much needed practice with the smaller 0402s. Just send me a chat message if you (or anyone else?) are interested.