nRF5 action!

somehow I cant change the pins on my Ebyte module. Im trying to test with MockMysensors.
I want te TX set to pin nr. P0.06

I changed: MyBoardNRF.h and included nrf.h

#define PIN_SERIAL_RX (8)
#define PIN_SERIAL_TX (6)

but somehow the TX pin stays P0.25.

Can someone point me in the right direction?

The node connects to the gateway, so thats also working.

Seems like that if you put the MyBoardNRF5 files into the example map and you change some things in that file using the Arduino IDE, it doenst get uploaded. When I changed the MyBoardNRF5 file using Brackets it working as intended.

Weird: the processor says it is in reset state? Could it be that it is not so much protected, but that it is constantly being reset? But then why is this with all the chips?

Once the OpenOCD server is running I also tried getting into the chip with

telnet localhost 3333

But then I get "Error: attempted 'gdb' connection rejected"

The OpenOCD documentation mentions the chip protection:

Flash Driver: nrf5
All members of the nRF51 microcontroller families from Nordic Semiconductor include internal flash and use ARM Cortex-M0 core. Also, the nRF52832 microcontroller from Nordic Semiconductor, which include internal flash and use an ARM Cortex-M4F core.
flash bank $_FLASHNAME nrf5 0 0x00000000 0 0 $_TARGETNAME
Some nrf5-specific commands are defined:
Command: nrf5 mass_erase
Erases the contents of the code memory and user information configuration registers as well. It must be noted that this command works only for chips that do not have factory pre-programmed region 0 code.http://www.openocd.org/doc/html/Flash-Commands.html

I also got out my voltmeter. Pin 21 and pin 25 have 3v on them, the rest don't.

@alowhum I'm not in sync with the whole thread , but I had similar issues when I had an FTDI adapter connected with @NeverDie 's breakout.
As soon as I disconnected the DTR (reset) line the thing started to work!

@alowhum I intentionally asked you because I know the problem exists.
You need to erase the chip via Jlink Commander. Neither nrfjprog nor anything alse will work (AFAIK)
Actually, it was @NeverDie who found it in the beginning of his quest with nrf52. "The thing that started it all" (c)

I got a gateway that's sitting upstairs when I connect an Ebyte module I must be right underneath the gateway to let it receive packages.
When I do exactly the same same thing with an NRF52832-DK It doesn't matter where I'm standing, every message is received by the gateway.

@omemanti Maybe by using a properly tuned external antenna? At least for the built-in antenna's, the Fanstel modules seem to have more effective Tx reach than the Ebyte modules do. That's a major reason for my switch from the Ebyte's to the Fanstel's.

, that makes sense. That's why on my PCB's I have the antenna portion of the module hanging over the edge of the PCB into e

yeah, next one will be a big hole in the middle, lets see how that will work out..

Interesting board !
But module in the middle is a bad idea, even with a big hole below the antenna it will affect performance to still have some PCB around
For example here is an extract of the Fanstel BT832 module datasheet. It's not the same antenna design but it show having the antenna sticking out is the best solution, else you should but as close as possible to the edge and of course keep ground plane and traces as far as possible.

@nca78 I'm trying to create a node that fits inside a standard wallsocket. (I'll post it when it's done) it got a motion and moisture sensor.

For the next version I'm moving the module more to the outside but I need to take the screwholes into account.
The groundplane I used filled the entire PCB, next one will have less ground around the antenna or even holes.

It's designed to hold 3 AA batteries to have a couple years of service.

But cutting away that spot around the antenna gave me reception throughout the entire house

I tried also with st-link but I think it doesn't support dap commands? Can anyone confirm that?

After clearing access protection I am able to successfully flash chip with st-link.
Now it shows in logs:Info : nrf52.cpu: hardware has 6 breakpoints, 4 watchpoints
Before it was:Info : nrf52.cpu: hardware has 0 breakpoints, 2 watchpoints

@maciekczwa If you could share a guide to unlocking these devices, I would be very grateful. I'm have a bit of trouble still. I create an JLink device form an STM32. But even that gives the same general error on all my modules.

@alowhum I intentionally asked you because I know the problem exists.
You need to erase the chip via Jlink Commander. Neither nrfjprog nor anything alse will work (AFAIK)
Actually, it was @NeverDie who found it in the beginning of his quest with nrf52. "The thing that started it all" (c)

Furthermore, It would be nice to have a small step-by-step guide to unlock and then program the ebyte module.@Omemanti and @NeverDie are using these modules, so should be able to write something up that works for other ppl

@Omemanti and @NeverDie are using these modules, so should be able to write something up that works for other ppl

As I've said many times previoiusly, I use the nRF52 DK to program external modules, and it's what I recommend for noobs because it's relatively hassle free. If you're able to use the $2 st-link v2 programmer then great, my hat's off to you. If not, I recommend the nRF52 DK rather than get frustrated and give up.

@Omemanti I didn't realise the nRF52-DK was a hardware device. I thought it was a software program.

On the picture you provided (thanks!), are pin 6 and 8 connected to a serial port to read what's going on? Your ground is connected in a different place than mine (I connect it next to the VCC pin). I suspect both those side-pins near the antenna, at the top, where you have soldered something, are ground too, right?

@Toyman yep, this confirms what i said, not difficult to access.
I didn't read the description..just looking at the pcb layout was enough to tell me poor rf range + no basic usb spec design rules (latter point is maybe not the most critical for most of people, but it just shows 1) designer wasn't aware ?? 2) this is what you get for cheap money, whereas missing parts would have cost few cents..).
Just saying, because maybe this dongle can work well enough for some people.

@scalz
I would be interested in any range testing in regard to this dongle. For ground it has whatever it is that it is plugged into. (PC, SBC, USB extention cable, etc) There will be a nRF52840 based dongle out soon. See picture above. This dongle will need to be programed over the SWD lines. No Segger on board this one..!

@Nca78
Getting rid of the ground plains around the entire module hugely improved the range. Had to stap back to AAA batteries to fit on the board. But I'm happy with the way it's going (AA is still possible but not soldered on it just doesn't fit enough in the wall socket)

It was very hard to extrude it, so I always seemed to either underextrude or overstrude. I found it very hard to get the right amount exactly where it should go by just manually pressing the plunger on the solder paste syringe that the material came in.

Yes I had the same problem too... added with too old solder paste from my local shop
I just ordered a stencil together with my test PCB, I guess it's the way to go given the now very low prices of stencils (mini-stencils at 9.9$ at Seeed and I just paid 7$ + 2$ PCB at JLCPCB, same company than EasyEDA).

Hello guys. Finally I've got some nrf51288 boards, like used here: https://www.openhardware.io/view/510/Button-cell-Temperature-Humidity-sensor I've hooked it up to ST Link, uploaded test sketch and everything worked fine. Then I tried to put it to sleep and measure power consumption. The best number I'm getting is 550uA... And it seems like something is completely wrong with this. Either my readings, or some bug in new version of Mysensors library or nrf5 arduino core.
To be sure it's not particular chip's bug I've checked both I've got, no differences. I've also checked current on stock BLE firmware from manufacturer it was running when they came. It was around 120uA - 200uA while presenting via bluetooth. So I guess it can't be that my readings are completely wrong. But then how can it be that bluetooth presenting consume less current than sleeping?
For now I couldn't find a solution or any hint for this, so I apologize If I am missing something, but I need help.

EDIT: I might just delete this post, but maybe someone will search for the same solution. Long story short 600uA extra is due to the lack of low frequency crystal onboard. It makes HFCLK to not shutdown and draws current during a sleep. I knew, that synth RTC will take more current but I didn't expect it to be that much.
Another question is why sleep that depends on pin change and seems doesn't require RTC consumes 1ma? I'm confused...

I know that this code is wrong, as it doesn't enable peripherals after wake up, and it I just took chunks of code from different places trying to disable whatever is running by mysensors and consumes that extra current. So in sleep this code consumes 200-230uA.

All is running on WT15822 board like this:
It doesn't have 32KHz crystal, but I program it using "Crystal Oscillator" from board menu of nrf5 arduino core.
As far as I understand some of the periferals and/or interrupts and/or timers is used by Mysensors stack and doesn't shut down when going to sleep, so it tries to use RTC, which is not available, so it wokes HFCLK, so it consumes extra current. A lot more than it should in sleep mode.

I need help with this, as I am planning to build a bucnh of simple window sensors on this board and they doesn't require wake by timer, but will be woken by extrnal pin interrupt. But for now I just can't use Mysensors sleep function to do this, because as I have described it works not as expected. Hope to get some response from you guys.

Just to set your expectations correctly: Very few MySensors users have tried nrf5 so far, so the combined experience is quite low. Hopefully someone has an idea on how to help you, but it could very well be that you're the community's most experienced user in this area thanks to your work.

@monte thé HFCLK is on because of a hardware bug in nrf51822 when you want to wake up using pin interrupt. You have to use PORT interrupt to go really low (around 5uA).

I made some (dirty) test code to validate that with MySensors but there was not much interest in that in the forum so I switched to something else. I will not use nrf51822 but nrf52832/40, they became really cheap now and don't have this hardware bug.

@nca78 The Rev C (COO) parts are available now and they are the production parts. (Symmetry and Nordic's other distributors have these in stock) There will be a respin of this to a Rev D to fix the REG0 issue. FYI, the current nRF52840 package is not a WCSP. It is a aQFN package. The nRF52840-Dongle is also available now. Go forth and design......

@nca78 well, after 2 nights of intense trying and failing I've got code to work as expected. And yes, it works with PORT interrupt, its kinda more code for you to write in compare to simply using attachInterrupt function, but I'm okay with that. For me double the price of 52832 compared to 51822 is significant. And for now, for a simple sensor stuff as we do with mysensors I don't really see any advantages except that interrupt bug fixed.
Also I've found that Mysensors sleep function for nrf5 is missing one very important command, I don't know why, maybe it is nrf51822 specific and thus @d00616 missed it but in current version of Mysensors library it doesn't disable UART before sleep, that's why I was getting 120-200uA current during sleep. I still don't really know how to make pull requests on github, so I guess I will just post it here:line 290 of MyHwNRF5.cpp should contain: NRF_UART0->ENABLE=0; and line 327: NRF_UART0->ENABLE=1; respectively. That completely disables UART on nrf51822.
I will post my complete sketch later, when I will finish it, maybe someone who strugles as I did will find it useful. Also I think we need to somehow combine all examples that were posted in this thread or at least put a list of them with links, because looking through 1654 posts is not an easy task, especially if you not sure what you are looking for exactly.

@smilvert I think I solved issues I mentioned. But I don't have final code yet as I am waiting for parts to arrive for my board. But I think there is no problem using WT51822 board except that you'll have to manually set PORT interrupt and also set pin SENSE register which is cannot be done with arduino function pinMode().
So I guess you can order PCBs if you want, I'm going to post final sketch with explanations at the end of the month.

@omemanti It seems like some peripherals are not shut down before sleep. As library you've mentioned uses Wire library, it must be TWI (i2c) interface that are active during sleep and consumes extra power. I'm afraid that you will have to manually disable/enable TWI around sleep routine.
EDIT: I see you've found an answer by yourself. Just want to clarify that it isn't nrf5 chip's fault, it just how it intended to work. It doesn't automagically disable all peripherals during sleep. So, someone should write low current sleep library for nrf5 specifically, that will check the state of peripherals before sleep and disable them if needed.

It has 256K RAM and 1MB of flash. I'm having difficulty imagining which applications would require that much of either one. If it were free, that would be great, but I'm afraid the large RAM becomes an energy drain. For instance, it consumes 3.16µA with System ON, full 256 kB RAM retention, and wake on RTC.

On the other hand, it consumes 0.4uA of current if System OFF, no RAM retention, and wake on reset

It consumes 16.4ma if transmitting at full power (8dBm) with DC-DC engaged.

If compared to LoRa, it's going to lose on range. However, the question is: will it be good enough in a large or otherwise difficult home environment? The specs say it should be better than either nRF24L01 and nRF52832, which seem better suited to smaller dwellings. Maybe (?) the question can be answered with a couple of dongles.

@neverdie I want to, but only shop that can send me with free shipping (and not 75$ like the others) is Arrow, and it's not yet in stock there.
CDEByte sells some too now ... but with a small form factor & ceramic antenna, I'm afraid it will waste all the theoretical extra range...

@neverdie
In fact it can.
Adafruit has a build of their Circuitpython (Micropython fork) for the nrf52832, and there's already an early alpha for the nrf52840.
As the 52840 has native USB, they can use Micropython as it was originally intended to be, with a virtual USB drive that contains all the user code files.

I'd like to take a crack at prograamming the nRF52840. Has anyone here tried it? I'm not sure whether the software support for it is in place yet or not. How best to get started with it? As far as compiling and uploading code goes, do I just treat it the same as an nRF2832?

@neverdie I have ordered 10x nRF52832 and 2x nRF52840 from EBYTE (E73-xxxB/C). I will join you once I got them (they are on they way since 2 weeks). I'll also work together with ransyer to get new PCB's (the last we maybe together are for the ESP32).
I'm curious what distance I can get indoor with the BLE 4.2/5.0 (no extra radio) and if required, I will combine it with a LoRA RFM95 (that is also what our PCB's is made for RFM69/95 and CC1101).
I'm still working on the sensor with the 1,54" ePaper (where the ATMEGA328p is lost with its 32kB flash and even worse with the 2k RAM)

So, I think I may give mbed a try for programming the nRF52840, because mbed claims to support the nRF52840-DK. Also, I found what seems like a nice and simple youtube tutorial series for how to use mbed: https://www.youtube.com/watch?v=kP_zHbC_5eM

If I have success with mbed, I may circle back to the Sandeep library and the mysensors implementation, but I'd like to start with something solid, and it appears that mbed might be.

The other nice thing is that it appears mbed provides an abstraction layer which makes easy to program a whole range of different mcu's, incuding many of the stm32's.

Update:
I received some nRF52840 dongles. I confirmed with Nordic that the recommended way to program them over USB is to use nRF Connect v2.5.0 which contains the nRF Programmer v1.0.0-experimental.5 application. I tried that, but I may have somehow bricked my first dongle by not pressing reset first before the upload. Either that, or because my simple program didn't initialize the USB, maybe it can't be found for that reason (I suspect so).

Luckily, I live not too far from Mouser. I should be receiving the nRF52840-DK today, so I figure that way I can unbrick the dongle.

Yesterday I played around with mbed on an nucleo board. Seems to work well (no bricking). Unfortunately, the dongle isn't an mbed device, so the methods above are required unless you program it with a DK or similar. The good news, though, is that the DK is an mbed board, so hopefully that will be smooth sailing. It turns out that USB is built into the nRF52840 chip, so it doesn't require a separate chip like a CP2102 to communicate over USB. I guess that can be good or bad depending on how your write your code.

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.