GUIDE - NRF5 / NRF51 / NRF52 for beginners
-
After correcting a wiring error (duh!) I was able to erase using my J-Link Mini EDU.
I used Nordic's nrfjprog:
nrfjprog --family NRF52 --recover
nrfjprog --family NRF52 --recoverI had to run it twice to get the unlock. I think this makes sense after reading the devzone article.
Once unlocked, I could use my black magic probe for programming. I expect the blackmagic folks haven't had time to adapt to the new lock scheme yet.@nagelc said in GUIDE - NRF5 / NRF51 / NRF52 for beginners:
After correcting a wiring error (duh!) I was able to erase using my J-Link Mini EDU.
I used Nordic's nrfjprog:
nrfjprog --family NRF52 --recover
nrfjprog --family NRF52 --recoverI had to run it twice to get the unlock. I think this makes sense after reading the devzone article.
Once unlocked, I could use my black magic probe for programming. I expect the blackmagic folks haven't had time to adapt to the new lock scheme yet.For future reference, yet another way you can also erase your chip is using the "Programmer" app that you can install into "nRF Connect for Desktop" program. Just connect and press the "Erase All" button:
I find that I have to do this in order to unlock the chip for the first time prior to enabling the reset pin with the code:
// Note: if chip has never been mass erased, then most likely PSELRESET[0] and PSELRESET[1] are both zero. // When that is the case, the chip is locked and neither can be set to 21. if (((NRF_UICR-> PSELRESET[0])==0xFFFFFFFF) && ((NRF_UICR-> PSELRESET[1])==0xFFFFFFFF)) { //if the two RESET registers were erased by a mass erase NRF_NVMC->CONFIG=1; // Write enable the UICR //Note: BOTH registers must be set to 21, or else PIN00.21 will not function as a RESET pin. NRF_UICR-> PSELRESET[0]= 21; //designate pin P0.21 as the RESET pin NRF_UICR-> PSELRESET[1]= 21; //designate pin P0.21 as the RESET pin NRF_NVMC->CONFIG=0; // Put the UICR back into read-only mode. } -
Well, I take it back. Although the above method worked for doing an "erase-all" and unlock the nRF52832 that's built into the nRF52-DK, it isn't doing anything to unlock a nRF52805 that's externally connected to an nRF52-DK. "Erase all" does seem to erase the program that on the nRF52805, but it nonetheless doesn't allow access to the reset registers NRF_UICR-> PSELRESET[0] and NRF_UICR-> PSELRESET[1]. I say that because, for instance, NRF_UICR-> PSELRESET[0] and NRF_UICR-> PSELRESET[1] are still zero after the "erase all" instead of 0xFFFFFFFF, and attempting to write them both to 21 fails.
I also tried nrfjprog:
nrfjprog --erase all
nrfjprog --recover
nrfjprog --resetpinenable
nrfjprog --family NRF52 --recover
nrfjprog --family UNKNOWN --recover
nrfjprog --eraseuicrand after each try the nRF52805 still has the reset registers impervious to writing.
Well, I see that the nRF52805 has been blessed with some kind of fancy new access port protection (APPROTECT), but reading the value of NRF_UICR->APPROTECT, it is currently at 0xFFFFFFFF, which means that APPROTECT is disabled.
So, not sure what to do about this one.
-
For anyone who may be interested, this is what the current draw on an nRF52805 looks like when it's sleeping:
It's about the same whether it's using DCDC mode or LDO mode when the system is sleeping in ON mode. When I first saw this plot I thought the MCU was waking up, doing something, and then falling back to sleep on what seemed like a very repeatable periodicity. I even went hunting for some part of the system that I had forgotten to turn-off that might be causing this behavior. However, when that hunt didn't turn up anything, my present theory is that this is just how the low power mode works when the system is ON but in sleep mode: it maybe is more efficient to sip current at periodic intervals than it is to run the LDO/DCDC continuously.
Now that you've seen the above picture of the spikey nature in which a nRF52 module draws its sleep current, you can appreciate that using a uCurrent Gold or a Current Ranger (let alone a multimeter) to measure sleep current is likely to give an erroneously low measurement: these pulses pass by too quickly for such a meter to properly register. That's why, for instance, I began to suspect that this guy's measurements were possibly too low:
https://www.youtube.com/watch?v=7sMbcyYS9osIndeed, when I hook my same sleeping module up to a current ranger, the current ranger shows 0.0ua when set in ua mode. In na mode, though, the measurements are jumping around all over the place. The point being: if that was all I had to go on, I'd probably erroneously conclude that the sleep current was something less than 1ua, whereas the PPK2 here is reporting an average 5.3ua within its measurement window.
What remains unexplained is why the average current draw I measured with PPK2 while sleeping like this is so high. According to the nRF52805 datasheet, the current drawn while sleeping in system ON mode with full memory retention should be just 0.8ua.
and so I'm not sure why I'm experiencing so much more than that (5.3ua in this PPK2 example), unless maybe it's something about the Fanstel BC805M module that it's a part of which is raising the sleep current. If so, that would certainly be disappointing: I bought it precisely because the nRF52805 is supposed to have such a low sleep current compared to the other Nordic nRF52 chips that are out there.
As a matter of fact, the spikey nature of the current draws led me to wonder whether maybe the PPK2 itself was perhaps not measuring the current correctly. So, to answer that, I added a 220uF bypass ceramic capacitor (i.e. between VCC and GND) near the nRF52805 module to better average out the current draw seen by the PPK2, and then I measured using the PPK2 again. Guess what? Now the PPK2 measures an average of 0.81ua, which is spot-on with what the datasheet predicted. Whew! What a relief. I find this new measurement trustworthy not only because (a) it agrees with the value predicted by the datasheet, but now also (b) both a PPK2 and a Current Ranger produce current measurements that agree with one another, and (c) by averaging out the current draw, the potential problems stemming from a highly spikey measurement are cast aside.
-
For anyone who may be interested, this is what the current draw on an nRF52805 looks like when it's sleeping:
It's about the same whether it's using DCDC mode or LDO mode when the system is sleeping in ON mode. When I first saw this plot I thought the MCU was waking up, doing something, and then falling back to sleep on what seemed like a very repeatable periodicity. I even went hunting for some part of the system that I had forgotten to turn-off that might be causing this behavior. However, when that hunt didn't turn up anything, my present theory is that this is just how the low power mode works when the system is ON but in sleep mode: it maybe is more efficient to sip current at periodic intervals than it is to run the LDO/DCDC continuously.
Now that you've seen the above picture of the spikey nature in which a nRF52 module draws its sleep current, you can appreciate that using a uCurrent Gold or a Current Ranger (let alone a multimeter) to measure sleep current is likely to give an erroneously low measurement: these pulses pass by too quickly for such a meter to properly register. That's why, for instance, I began to suspect that this guy's measurements were possibly too low:
https://www.youtube.com/watch?v=7sMbcyYS9osIndeed, when I hook my same sleeping module up to a current ranger, the current ranger shows 0.0ua when set in ua mode. In na mode, though, the measurements are jumping around all over the place. The point being: if that was all I had to go on, I'd probably erroneously conclude that the sleep current was something less than 1ua, whereas the PPK2 here is reporting an average 5.3ua within its measurement window.
What remains unexplained is why the average current draw I measured with PPK2 while sleeping like this is so high. According to the nRF52805 datasheet, the current drawn while sleeping in system ON mode with full memory retention should be just 0.8ua.
and so I'm not sure why I'm experiencing so much more than that (5.3ua in this PPK2 example), unless maybe it's something about the Fanstel BC805M module that it's a part of which is raising the sleep current. If so, that would certainly be disappointing: I bought it precisely because the nRF52805 is supposed to have such a low sleep current compared to the other Nordic nRF52 chips that are out there.
As a matter of fact, the spikey nature of the current draws led me to wonder whether maybe the PPK2 itself was perhaps not measuring the current correctly. So, to answer that, I added a 220uF bypass ceramic capacitor (i.e. between VCC and GND) near the nRF52805 module to better average out the current draw seen by the PPK2, and then I measured using the PPK2 again. Guess what? Now the PPK2 measures an average of 0.81ua, which is spot-on with what the datasheet predicted. Whew! What a relief. I find this new measurement trustworthy not only because (a) it agrees with the value predicted by the datasheet, but now also (b) both a PPK2 and a Current Ranger produce current measurements that agree with one another, and (c) by averaging out the current draw, the potential problems stemming from a highly spikey measurement are cast aside.
-
@NeverDie have you checked the radio already? How much work is needed to make it work with mysensors?
@monte said in GUIDE - NRF5 / NRF51 / NRF52 for beginners:
@NeverDie have you checked the radio already? How much work is needed to make it work with mysensors?
Answering your question: Presently taking baby steps. Using pseudo bare metal programming I have it sending and receiving very simple packets using the proprietary mode radio at 2mbps. Nothing fancy. Just the bare minimum. But it works, and the code is portable with no meaningful library dependencies other than just regular C-language libraries like string.h. :-) After I clean up the code I'll post it to github. I had already posted it on github in micropython and forth, and I just recently translated it back into C (which is what I had started with originally but didn't save the code :face_with_rolling_eyes: ). Anyhow, the benefit of writing it in pseudo bare metal is that it should pretty much compile without changes and run no matter which tool chain you're using (Sandeep, SES, or whatever). :slightly_smiling_face:
You know, it occurs to me that we should upload not just the source code, but a full VM of the development environment used to compile, link, and upload it. That would be smart. After all, all projects become time capsules, and who knows what toolchain or library will be in vogue years down the line when you want to make some change in the code you've written. If it's all in a VM, then you can step back right where you were without missing a beat. Hmmm.... I like this idea. So obvious, yet so powerful. The only problem I foresee is that J-link license is bound to the particular nRF52-DK that you own, so at least that part might make sharing a common VM a bit awkward. Everything would need to be either open source or free to use for a shared VM to work without incurring problems of its own.
But, anyway, details aside, a shared VM development platform would create a stable starting place for any newcomer who comes along. Even if the setup instructions are current at the moment they are written, over time entropy kicks in and eventually....you all know how that goes.....
And not just SW development. HW development too. For instance, rather than share just a kicad archive, if you could share a VM of the entire kiCad that you used to create a PCB.... that would be the ultimate. Then, if KiCad 7 comes along and isn't fully backward compatible with KiCad 6, everything still works just as well as it always did the moment you finished with it.
-
@monte said in GUIDE - NRF5 / NRF51 / NRF52 for beginners:
@NeverDie have you checked the radio already? How much work is needed to make it work with mysensors?
Answering your question: Presently taking baby steps. Using pseudo bare metal programming I have it sending and receiving very simple packets using the proprietary mode radio at 2mbps. Nothing fancy. Just the bare minimum. But it works, and the code is portable with no meaningful library dependencies other than just regular C-language libraries like string.h. :-) After I clean up the code I'll post it to github. I had already posted it on github in micropython and forth, and I just recently translated it back into C (which is what I had started with originally but didn't save the code :face_with_rolling_eyes: ). Anyhow, the benefit of writing it in pseudo bare metal is that it should pretty much compile without changes and run no matter which tool chain you're using (Sandeep, SES, or whatever). :slightly_smiling_face:
You know, it occurs to me that we should upload not just the source code, but a full VM of the development environment used to compile, link, and upload it. That would be smart. After all, all projects become time capsules, and who knows what toolchain or library will be in vogue years down the line when you want to make some change in the code you've written. If it's all in a VM, then you can step back right where you were without missing a beat. Hmmm.... I like this idea. So obvious, yet so powerful. The only problem I foresee is that J-link license is bound to the particular nRF52-DK that you own, so at least that part might make sharing a common VM a bit awkward. Everything would need to be either open source or free to use for a shared VM to work without incurring problems of its own.
But, anyway, details aside, a shared VM development platform would create a stable starting place for any newcomer who comes along. Even if the setup instructions are current at the moment they are written, over time entropy kicks in and eventually....you all know how that goes.....
And not just SW development. HW development too. For instance, rather than share just a kicad archive, if you could share a VM of the entire kiCad that you used to create a PCB.... that would be the ultimate. Then, if KiCad 7 comes along and isn't fully backward compatible with KiCad 6, everything still works just as well as it always did the moment you finished with it.
-
@monte said in GUIDE - NRF5 / NRF51 / NRF52 for beginners:
@NeverDie are you saying it is only programmable with j-link? Won't stlink/blackmagic work?
:face_palm: Yes, you're right. Either of those should work. I happen to be using j-link, so that gave me tunnel vision, but if either or those were the basis, then problem solved!
BTW, I just now checked, and the module I'm using literally does fit on a dime:
$2.50 each. -
@monte said in GUIDE - NRF5 / NRF51 / NRF52 for beginners:
@NeverDie are you saying it is only programmable with j-link? Won't stlink/blackmagic work?
:face_palm: Yes, you're right. Either of those should work. I happen to be using j-link, so that gave me tunnel vision, but if either or those were the basis, then problem solved!
BTW, I just now checked, and the module I'm using literally does fit on a dime:
$2.50 each. -
@monte said in GUIDE - NRF5 / NRF51 / NRF52 for beginners:
@NeverDie sorry, where did you buy them? I don't see them anywhere :(
https://www.fanstel.com/buy/bt832f-low-cost-longer-range-bluetooth-50-module-cjtrx-8shlz-r7a7z
Presently sold-out of this particular model, but if you watch for it, it seems to come back into stock fairly often. When I was buying they had only 10 in stock, so I bought all ten. Then the next day they had another 15 in stocki, so I bought all 15. Then they were out of stock for a while, but then recently they re-stocked. Apparently that didn't last, because now they are already out of stock again.
-
@monte said in GUIDE - NRF5 / NRF51 / NRF52 for beginners:
@NeverDie sorry, where did you buy them? I don't see them anywhere :(
https://www.fanstel.com/buy/bt832f-low-cost-longer-range-bluetooth-50-module-cjtrx-8shlz-r7a7z
Presently sold-out of this particular model, but if you watch for it, it seems to come back into stock fairly often. When I was buying they had only 10 in stock, so I bought all ten. Then the next day they had another 15 in stocki, so I bought all 15. Then they were out of stock for a while, but then recently they re-stocked. Apparently that didn't last, because now they are already out of stock again.
-
@monte There are $1.59-$2.39 nRF52805 Minew modules on Alibaba: https://minewtech.en.alibaba.com/search/product?SearchText=nrf52805
The size is just a couple mm larger than the the dime sized BC805M (above photos). I've never ordered from Alibaba so I can't really say how well that may or may not go. i.e. maybe it's a good deal, or maybe it's clickbait pricing and they hammer you on shipping. For instance, unlike Aliexpress, I don't see a rapid way to place an order, which is kinda weird given that the minimum order is just quantity 3. I assume one has to send the seller an RFQ indicating the quantity desired, and then the seller responds with a price that includes shipping? Anyone know if that's how it works? Obviously I have no idea where the breakpoint is, but maybe if you were to order 20 or 30 you'd come out ahead vs ordering from Aliexpress. -
@monte There are $1.59-$2.39 nRF52805 Minew modules on Alibaba: https://minewtech.en.alibaba.com/search/product?SearchText=nrf52805
The size is just a couple mm larger than the the dime sized BC805M (above photos). I've never ordered from Alibaba so I can't really say how well that may or may not go. i.e. maybe it's a good deal, or maybe it's clickbait pricing and they hammer you on shipping. For instance, unlike Aliexpress, I don't see a rapid way to place an order, which is kinda weird given that the minimum order is just quantity 3. I assume one has to send the seller an RFQ indicating the quantity desired, and then the seller responds with a price that includes shipping? Anyone know if that's how it works? Obviously I have no idea where the breakpoint is, but maybe if you were to order 20 or 30 you'd come out ahead vs ordering from Aliexpress. -
@NeverDie I contacted alibaba sellers a few times for quotes, but never got to buy anything:) The process and shipping costs kills any wish to try and buy if anything less then 20-50...
Reporting back: Yeah, I just now contacted them. The price they're quoting now is $3.89 per module and they want $35 shipping. They said "Mass production is about 2.5-2.2 USD", which is higher than what their Alibaba listing says for quantity 3 sample pricing, which they now say is 2 years out date and should be ignored. Checking, I see that the quoted pricing is actually slightly worse than the $3.82/unit in their Aliexpress store. What a joke. I mean, given that this is allegedly the manufacturer talking, who can't be bothered to keep their own Alibaba listing updated even though it's allegedly two years out of date.... I guess the pricing indicated on Alibaba means nothing, which certainly explains a lot.
-
One shortcoming of the nRF52805 that I just ran across: it has no LPCOMP. I'm surprised, as it's rather basic functionality.
-
On the other hand, the nRF52805 does have PORT DETECT, which appears can provide the basic wake-up functionality at no penalty to current consumption. i.e. total sleep current remains at 0.8ua with full memory retention. AFAIK, that's still better than any of the other nRF52xxx chips Nordic has so far made, and in that one respect also better than what the nRF5340 can achieve. That compares to 0.5ua current draw when the nRF52805 is in OFF mode, with no memory retention, but where PORT DETECT could still be used to wake-up the nRF52805. So, the interesting question remains: how many mah are consumed by going from stone-cold 0ua OFF to full-on? Knowing that, one could compute the tradeoff of going that route vs sleeping at 0.8ua or 0.5ua. If the stone-cold OFF interval is long enough, it will win, and so the only unknown (currently) is how long that interval needs to be to reach a break-even point, and beyond that the energy savings pile up.
-
On the other hand, the nRF52805 does have PORT DETECT, which appears can provide the basic wake-up functionality at no penalty to current consumption. i.e. total sleep current remains at 0.8ua with full memory retention. AFAIK, that's still better than any of the other nRF52xxx chips Nordic has so far made, and in that one respect also better than what the nRF5340 can achieve. That compares to 0.5ua current draw when the nRF52805 is in OFF mode, with no memory retention, but where PORT DETECT could still be used to wake-up the nRF52805. So, the interesting question remains: how many mah are consumed by going from stone-cold 0ua OFF to full-on? Knowing that, one could compute the tradeoff of going that route vs sleeping at 0.8ua or 0.5ua. If the stone-cold OFF interval is long enough, it will win, and so the only unknown (currently) is how long that interval needs to be to reach a break-even point, and beyond that the energy savings pile up.
@NeverDie Oh I've been running around 20 NRF52805 nodes for the past ~2 years https://forum.mysensors.org/post/108893. They've been working very well for me.
edit:
PRs to get working with mysensors
https://github.com/sandeepmistry/arduino-nRF5/pull/442
https://github.com/mysensors/ArduinoHwNRF5/pull/12 -
Reporting back: I did the measurements, and it takes an nRF52805 about 750uSec to go from cold-start to turning on an LED, at an average current drain of about 330ua just prior to the LED turning on. Of course, the 805 may have to spend additional time and current to re-establish a particular context, but ignoring that, the measurements suggest a breakeven point between cold-start vs sleeping with the RTC turned-on and full memory retained (roughly 1.5ua current draw) is approximately 200ms. The downside is that it would require additional hardware to benefit from the arbitrage, but if so desired it could be done. In fact, just knowing that's it's possible makes me want to try it! :sunglasses:
-
@NeverDie Oh I've been running around 20 NRF52805 nodes for the past ~2 years https://forum.mysensors.org/post/108893. They've been working very well for me.
edit:
PRs to get working with mysensors
https://github.com/sandeepmistry/arduino-nRF5/pull/442
https://github.com/mysensors/ArduinoHwNRF5/pull/12@ncollins Impressive! Looks as though you even modeled the exact shape of the coincell holder. And you apparently designed the 3D printer snap enclosures as well. Even just the 3D printed enclosure modelling is quite a task all by itself. I hope to one day evolve into doing that too, but for now the Hammond enclosures are going to be my short-term solution. The smallest Hammond is still not as small as what you've managed to produce, but at 36mm wide for an off-the-shelf ABS enclosure, it's too wide by only about 10mm. Still.... one day I want to 3D print an enclosure to be as small as possible.
