nRF5 action!
-
@acb Thanks for your post!
My nRF52 skills have gotten a bit rusty, so in case you're no longer around when I circle back to this toopic in the future, I'm going to jump the gun and ask you now so that your answer can be memorialized here and then suitably curated by Hek for years to come: How exactly do you ensure that your bootloader is loaded into the proper bootloader memory segments and not treated like a regular program and stored in ordinary, non-privlidged program memory? I'm guessing it's accomplished through a linker directive of some kind? If you could share even a brief simple example here on how to implant the bootloader code where it needs to be, I'm sure it would be immensely helpful to anyone who wants to create a custom bootloader of their own. ;-)
Actually, it seems you did offer a summary of how to do it when you wrote "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.", but again a step-by-step actual example, with demo files, would really drive it home. Now, some people might consider that much detail would constitute a "no thinking required" guide and therefore overkill, but I'd prefer overkill to underkill any day. I'm sure at least some others who are reading this would rather have s complete demo example that's too basic than have to puzzle over a missing or vague step. It may not seem like it's missing or vague to you now, but believe me if you ever have to switch to a different project for a while, it might not look anywhere near as obvious or as familiar when you come back to pick up where you left off.
So, if I can prevail upon you to put together even a very simple demo, I'd volunteer right away as a test subject to see if I could replicate it. And if I can, then you can be confident that if you had to shelf your work then you could come back years later and resume without help just based upon re-reading your own notes. :sunglasses:
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? :)
@acb said in nRF5 action!:
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?
Yes to nRF52840. Dealer's choice as to which nRF52840 module--i.e. I'm neutral, so whatever is more convenient for you. I suppose for others reading this the dongle might be a good choice though.
The other side of this is the FreeRTOS side. Would you like examples for the lowest possible power?
Is FreeRTOS definitely required? I suppose I could live with it, but as a simple demo even just some simple code that did nothing more than blink an LED and which resided where the bootloader out to be and which got loaded automatically from protected memory on reset as though it were a real bootloader is sufficient. If I knew how to do that one small thing, then I presume I could extend it to be a real wireless bootloader instead of just an LED blinker. I'm just missing the info on how to put code into the privileged and normally protected bootloader location. I'm hoping it's actually pretty simple and straightforward and not something lengthy and complex like the way the Nordic SDK advocates doing it.
-
Update on my NRF52805 Breakout:
- I2C is now working, just a few small changes to select the right interface
- Power consumption looks good, around 1.8uA. The Si7021 module is reading 2.5uA in isolation.
Just need to test SPI and figure out a clever name for the board, and should be good to go.
@ncollins Hey any update on your NRF52805 Breakout work? I've got a couple of the Ebyte modules that I have been playing around with. Found your pull request on GitHub for board support in sandeepmistry's nrf5 core. Wondering if you got any further as the pull request hasn't been merged and it would be great to see Arduino support for these modules.
-
@ncollins Hey any update on your NRF52805 Breakout work? I've got a couple of the Ebyte modules that I have been playing around with. Found your pull request on GitHub for board support in sandeepmistry's nrf5 core. Wondering if you got any further as the pull request hasn't been merged and it would be great to see Arduino support for these modules.
@Jon-Raymond I kinda got hung up on the last conversation in the merge request and haven't looked at it since. Let me push the changes I have to address the other comments, then try to figure out how to best handle that last bit.
-
@Jon-Raymond I kinda got hung up on the last conversation in the merge request and haven't looked at it since. Let me push the changes I have to address the other comments, then try to figure out how to best handle that last bit.
@ncollins That's great, thanks!
-
@ncollins Hey any update on your NRF52805 Breakout work? I've got a couple of the Ebyte modules that I have been playing around with. Found your pull request on GitHub for board support in sandeepmistry's nrf5 core. Wondering if you got any further as the pull request hasn't been merged and it would be great to see Arduino support for these modules.
@Jon-Raymond I pushed my latest changes, posted a question to the merge about next steps.
-
@Jon-Raymond I pushed my latest changes, posted a question to the merge about next steps.
@ncollins Here is my version of a breakout for the nRF52805.
Been playing around with your fork/pull request and I do have one question.
Should there be a SoftDevice for this? According to Nordic it needs either S112 or S113 for BLE to function? Right now your pull request only has the "None" option in the SoftDevice menu.
Is this something you have run into? Do you have any example code that you are running on this module? Thanks again for your work in getting this device supported.
-
@ncollins Here is my version of a breakout for the nRF52805.
Been playing around with your fork/pull request and I do have one question.
Should there be a SoftDevice for this? According to Nordic it needs either S112 or S113 for BLE to function? Right now your pull request only has the "None" option in the SoftDevice menu.
Is this something you have run into? Do you have any example code that you are running on this module? Thanks again for your work in getting this device supported.
@Jon-Raymond the nRF52805 should support the S112 and S113 soft device, but I removed it from the menu because I never tested it and didn't intend to immediately use it.
Digging through sandeepmistry/arduino-nrf5, it looks like S112 and S113 aren't included in the SDK. It might be easy enough to just drop in two new folders, then update boards.txt.
(Just an example of how I would add a soft device option to the dropdown, these would have to match up with whatever is in the sdk)
I would recommend opening an issue/question on https://github.com/sandeepmistry/arduino-nRF5, specifically asking the best way to add a new softdevice to the library. If it's straightforward, I can work with you to get those changes incorporated and, hopefully, included in the merge request.
-
@Jon-Raymond the nRF52805 should support the S112 and S113 soft device, but I removed it from the menu because I never tested it and didn't intend to immediately use it.
Digging through sandeepmistry/arduino-nrf5, it looks like S112 and S113 aren't included in the SDK. It might be easy enough to just drop in two new folders, then update boards.txt.
(Just an example of how I would add a soft device option to the dropdown, these would have to match up with whatever is in the sdk)
I would recommend opening an issue/question on https://github.com/sandeepmistry/arduino-nRF5, specifically asking the best way to add a new softdevice to the library. If it's straightforward, I can work with you to get those changes incorporated and, hopefully, included in the merge request.
Thanks @ncollins. I created the issue as requested.
-
Thanks @ncollins. I created the issue as requested.
@Jon-Raymond Well, not seeing a lot of activity in the repo.
I took a very long shot at adding support https://github.com/nikolac/arduino-nRF5/tree/nrf52805-s112-support.
I was able to flash the softdevice, but I haven't tested or even uploaded a working sketch (sloppy). Feel free to mess around and test. If it works for you, I do the same for S113.
Biggest question I have is around figuring out the proper values for the "linker scripts" https://github.com/nikolac/arduino-nRF5/blob/nrf52805-s112-support/cores/nRF5/SDK/components/softdevice/s112/toolchain/armgcc/armgcc_s112_nrf52805_xxaa.ld
-
I've ordered an Adafruit Clue, which should be arriving today. It utilizes the nRF52840. Judging from the reviews, Adafruit has done a nice job of supporting both the Clue and the Clue's vast number of built-in sensors with 1. good adafruit library integration along with lots of example programs and 2. the adafruit bootloader, making it easy for beginners to program the Clue via the familiar Arduino IDE. For those just getting started, I think it's likely to be a more satisfying experience and a gentler introduction to nRF5x than buying a nRF5x DK and then wondering what to do next.
-
I've ordered an Adafruit Clue, which should be arriving today. It utilizes the nRF52840. Judging from the reviews, Adafruit has done a nice job of supporting both the Clue and the Clue's vast number of built-in sensors with 1. good adafruit library integration along with lots of example programs and 2. the adafruit bootloader, making it easy for beginners to program the Clue via the familiar Arduino IDE. For those just getting started, I think it's likely to be a more satisfying experience and a gentler introduction to nRF5x than buying a nRF5x DK and then wondering what to do next.
I received the CLUE and it works very nicely--just like you'd expect a proper Arduino board to work: some basic hardware abstraction, a familiar easy-to-use Arduino IDE, easy familiar compiles, easy familiar uploads, and easy familiar access to serial input/output.
Time flies! This thread is already 5 years old, but I'm re-reading it now to refresh myself on all the little details that I've forgotten.
-
Anyone here programmed an nRF52805? I made a breakout board for one and was planning to program it using the J-LINK on an nRF52-DK:
but because there is no official DK for the nRF52805, there is no "board" for it, and so I'm unclear as to how exactly it is supposed to be programmed. Segger Embedded Studio makes no mention of the nRF52805 at all, as near as I can tell. Fortunately, our old friend Sandeep Mistry does appear to have a core for it: https://github.com/sandeepmistry/arduino-nRF5/tree/master/cores/nRF5/SDK/components/device
so that may help save the day. Unfortunately, the nRF52805 upload instructions from Nordic are a hassle: https://devzone.nordicsemi.com/guides/short-range-guides/b/getting-started/posts/developing-for-the-nrf52805-with-nrf5-sdk Is there no easier way? -
Reporting back: As a first step I programmed an external nRF52832 by blinking P.18 using this method for wiring it up: https://devzone.nordicsemi.com/f/nordic-q-a/14058/external-programming-using-nrf52-dk This method of wiring is worthy of note all by itself, because prior to now the conventional wisdom was that the target mcu had to be separately, externally powered for the J-link on the DK to recognize it properly. With the illustrated approach to wiring it up, though, you can power it from the DK itself.
Nice.That worked just fine. Then I tried uploading exactly the same code, using the same wiring scheme, to the nRF52805. I even erased it beforehand just to be sure.
According to J-Link, both the erasure and the subsequent upload were successful. However, P.18 does not blink. So, it would appear that a straightforward upload by treating it like an nRF52832 just isn't going to work, even just for blinking a particular pin. Argh! I feared as much. Disappointing! -
Success! Treating the nRF52805 like an nRF52810 and uploading to it from Segger Embedded Studio's IDE using Nordic's nRF52 SDK's PCA10040e board definition, then pin P.18 blinks using the same sketch that blinked P.18 on the nRF52832. I'm reporting back with this good news, because I haven't seen it tried or documented anywhere before. At least for this modest first attempt, this simple spoof works! At $2.50 each, these tiny nRF52805 modules with their trace antennas are a good value.
By the way, the compiler that's built into Segger Embedded Systems is super fast compared to gcc.
