GUIDE - NRF5 / NRF51 / NRF52 for beginners

[alowhum]

@billgoolsby I don't know about other NRF24 libraries. But MySensors definitely works.

@smilvert: I am not an expert, I'm a beginner sharing what I learnt so far. Perhaps other experts on the forum can help. It's probably a good idea to post advanced questions in the NRF5 thread.

[xmonika]

I am starting to experiment with NRF51822. Thank you all for this thread. I am stuck with setting up IDE on Win10 and my MCU is not communicating. What is the correct setup for Arduino IDE?
I have Port still grayed out and error: The selected port not exist

Could that be related to drivers? I've run Zadig, there are more options and I've tried all four of them

I am not able to upload even erase sketch. Any suggestion where to focus (IDE/Zadig/other)?

[mfalkvidd]

@xmonika which programming tool are you using? ST-Link v2? Could you post a photo of your wiring?

[Omemanti]

@xmonika have you tried to erase it? In most cases if is start with a new module I first need to erase is once.

Shortcut => burn bootloader, this will give an error but you should be good to go from there.

[xmonika]

@omemanti @mfalkvidd Thank you, I think I did it. It works now - or I hope so from the code.

** Programming Finished **
** Verify Started **
nrf51.cpu: target state: halted
target halted due to breakpoint, current mode: Thread 
xPSR: 0x61000000 pc: 0x2000002e msp: 0x20004000
verified 1412 bytes in 0.038633s (35.692 KiB/s)
** Verified OK **
** Resetting Target **
shutdown command invoked

What I was confused is that there is erase sketch, but to make it erased there is this trick with burn bootloader. Still the port is greyed out, but it seems I am able to flash blank sketch. Thanks

[Omemanti]

@xmonika I use the ST-Link, mine is always greyed out. The only time im able to select a port, it's when I'm using an FTDI to use the serial monitor. So I think everything looks normal.

[ileneken3]

@omemanti

I have tried EVERYTHING to get an ST-LINK V2 to program an NRF52. That includes - multiple ST-LINK's, multiple computers, Linux, "burn bootloader" first, and pretty much everything I could read on this forum. The error message is always:

Open On-Chip Debugger 0.10.0-dev-00254-g696fc0a (2016-04-10-10:13)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
debug_level: 2
0x4000
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 10000 kHz
Info : Unable to match requested speed 10000 kHz, using 4000 kHz
Info : Unable to match requested speed 10000 kHz, using 4000 kHz
Info : clock speed 4000 kHz
Info : STLINK v2 JTAG v32 API v2 SWIM v7 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.252590
An error occurred while uploading the sketch
Error: init mode failed (unable to connect to the target)
in procedure 'program'
in procedure 'init' called at file "embedded:startup.tcl", line 473
in procedure 'ocd_bouncer'
** OpenOCD init failed **
shutdown command invoked

Any ideas?

Thanks!

[NeverDie]

Are you powering the target from an external power source? If not, try that.

[ileneken3]

Unfortunately- I did try that - although without an led it’s hard to know if the board really is getting power. I will check with a multimeter.

[Omemanti]

@ileneken3 said in GUIDE - NRF5 / NRF51 / NRF52 for beginners:

hat - although without an led it’s hard to know if the board really is getting power. I will check with a multimeter.

did you use zadig to install the drivers for the ST-Link?

[ileneken3]

@omemanti

Yes, I used Zadig. From the Device Manager in Windows, it displays "STM32 STLink" when the programmer is plugged in.
In Linux, the device seems to be recognized automatically without installing any drivers.

[ileneken3]

@ileneken3

Yes, I'm connecting 3.3 volts to VCC and GND on the board, while connecting the programmer to the PC's USB port. I'm assuming there is no need for a common ground?

Oh well...

[Omemanti]

This post is deleted!

[ileneken3]

@ileneken3
After giving up on the cheap (illegal?) ST-LINK and J-LINK boards, I decided to make my life easy and get a NRF-DK. Unfortunately, even that is not easy enough . I did manage to use nRFgo Studio to flash a pre-built .hex file (blinky_pca10040.hex) to the EBYTE E73 module. I know it works because I attached an LED to a pin on the module and I see it blinks. But I can't do what I really want - flash a simple Mysensors sketch (preferably with the Arduino IDE).
Everything compiles OK, I'm using the very latest MyBoardNRF5 board definition (including the Sandeep Mistry libraries). But the Arduino IDE won't recognize the J-LINK programmer that is built into the DK board. (Maybe that's not expected to work?)

As a workaround, from the Arduino IDE, I select "Export compiled Binary", and then use the resultant .hex file with nRFgo Studio to flash the board. Everything seems fine, but I get no indication from the gateway that any wireless traffic is received from the board - so I assume it is not working at all. Below is the sketch.

#define MY_RADIO_NRF5_ESB
#define MY_DEBUG
#define MY_NODE_ID 10 // 0x0a nrf test
#define CHILD_ID 55  // Id of the sensor child

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


// Initialize motion message
MyMessage msg(CHILD_ID, V_TRIPPED);


bool value = 1;
void setup() {
  Serial.println("I am starting");

    send(msg.set(value)); // Get things started
    
  // initialize digital pin LED_BUILTIN as an output.
  //pinMode(13, OUTPUT);
}

void presentation()  {

  sendSketchInfo("NRF52", "0.9");

  present(CHILD_ID, S_MOTION);
}
void loop() {
  Serial.println("I am in a loop");
  //digitalWrite(13, HIGH);   // turn the LED on (HIGH is the voltage level)
  //delay(3000);                       // wait for a second
  //digitalWrite(LED_BUILTIN, LOW);    
  delay(3000);                       // wait for a second

}

P.S.
I have not managed to get any console output using the TX/RX pins to work either.
It would really brighten up my holidays if someone could point me in the right direction!

Thanks,

[Omemanti]

@ileneken3 1. how did you wire the DK tot the target module?

https://forum.mysensors.org/topic/6961/nrf5-action/1744

1. What is the error the Arduino IDE produces?
2. Can you also post the myboardnrf(sounds like..) files?

FYI, I both use the stlink and nrf52832-DK for programming. And I'm pretty sure the stlink I use is not so original. 2 dollar each.

[ileneken3]

@omemanti

1. I wired the DK to the target exactly as described in the article, and as drawn in the picture:
   https://devzone.nordicsemi.com/f/nordic-q-a/20536/programming-external-custom-nrf52832-board-using-nrf52-dk
   I am assuming everything is correct in the wiring, because I was able to flash the blinky pre-compiled hex file and it works.
2. When selecting J-Link as the programmer, the error from the Arduino IDE is:

C:\Users\krakman\AppData\Local\Arduino15\packages\sandeepmistry\tools\openocd\0.10.0-dev.nrf5/bin/openocd.exe -d2 -f interface/jlink.cfg -c transport select swd; set WORKAREASIZE 0; -f target/nrf52.cfg -c program {{C:\Users\krakman\AppData\Local\Temp\arduino_build_268238/MyBoardNRF5tst.ino.hex}} verify reset; shutdown;
Open On-Chip Debugger 0.10.0-dev-00254-g696fc0a (2016-04-10-10:13)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
debug_level: 2
0
adapter speed: 10000 kHz
cortex_m reset_config sysresetreq
jaylink: Failed to open device: LIBUSB_ERROR_NOT_FOUND.
Info : No device selected, using first device.
Error: No J-Link device found.
Error: No Valid JTAG Interface Configured.
Error: No Valid JTAG Interface Configured.

/*
  If you don't use an nRF5 board, you can ignore this file.
  
  This file was part of the "My Sensors nRF5 Boards" board repository
  available at https://github.com/mysensors/ArduinoBoards If you have
  questions, please refer the documentation at
  https://github.com/mysensors/ArduinoHwNRF5 first.
  
  This file is compatible with ArduinoHwNRF5 >= 0.2.0

  This file allows you to change the relation between pins referenced in
  the Arduino IDE (0..31) and pins of the nRF5 MCU (P0.00..P0.31).
  
  If you can live with addressing the GPIO pins by using the Arduino pins
  0..31 instead of a custom mapping, don't change this file. If you have
  a lot of Arduino code with fixed pin numbers and you need to map these
  pins to specific pins of the nRF5 MCU; you need to change this file.
  
  If you fill the "g_APinDescription" Array with numbers between 0..31,
  the Arduino pins 0..31 are assigned to pins P0.00..P0.31 of the MCU.
  
  As an example, if you need to change the pin mapping for Arduino pin 5
  to P0.12 of the MCU, you have to write the 12 after PORT0 into the sixth
  position in the  "g_APinDescription" Array.
   
  The extended attributes only affects the nRF5 variants provided with
  official Arduino boards. The arduino-nrf5 variant ignores the extended
  attributes.
    
  The pin mapping effects commands like "pinMode()", "digitalWrite()",
  "analogRead()" and "analogWrite()".
  
  If you change the pin mapping, you have to modify the pins in
  "MyBoardNRF5.h". Especially the analog pin mapping must be replaced with
  your pin numbers by replacing PIN_AIN0..7 with a number of your mapping
  array. You can use the constants PIN_AIN0..7 in the "g_APinDescription"
  Array if you want to reference analog ports MCU independent. You cannot
  use the pins P0.00 and P0.01 for GPIO, when the 32kHz crystal is connected.

  
  ###########################################################################

  Copyright (c) 2014-2015 Arduino LLC.  All right reserved.
  Copyright (c) 2016 Arduino Srl.  All right reserved.
  Copyright (c) 2017 Sensnology AB. All right reserved.

  This library is free software; you can redistribute it and/or
  modify it under the terms of the GNU Lesser General Public
  License as published by the Free Software Foundation; either
  version 2.1 of the License, or (at your option) any later version.

  This library is distributed in the hope that it will be useful,
  but WITHOUT ANY WARRANTY; without even the implied warranty of
  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
  See the GNU Lesser General Public License for more details.

  You should have received a copy of the GNU Lesser General Public
  License along with this library; if not, write to the Free Software
  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
*/



#ifdef MYBOARDNRF5
#include <variant.h>

/*
 * Pins descriptions. Attributes are ignored by arduino-nrf5 variant. 
 * Definition taken from Arduino Primo Core with ordered ports
 */
const PinDescription g_APinDescription[]=
{
  { NOT_A_PORT, 0, PIO_DIGITAL, PIN_ATTR_DIGITAL, No_ADC_Channel, NOT_ON_PWM, NOT_ON_TIMER}, // LFCLK
  { NOT_A_PORT, 1, PIO_DIGITAL, PIN_ATTR_DIGITAL, No_ADC_Channel, NOT_ON_PWM, NOT_ON_TIMER}, // LFCLK
  { PORT0,  2, PIO_DIGITAL, (PIN_ATTR_DIGITAL|PIN_ATTR_PWM), ADC_A0, PWM4, NOT_ON_TIMER},
  { PORT0,  3, PIO_DIGITAL, (PIN_ATTR_DIGITAL|PIN_ATTR_PWM), ADC_A1, PWM5, NOT_ON_TIMER},
  { PORT0,  4, PIO_DIGITAL, (PIN_ATTR_DIGITAL|PIN_ATTR_PWM), ADC_A2, PWM6, NOT_ON_TIMER},
  { PORT0,  5, PIO_DIGITAL, (PIN_ATTR_DIGITAL|PIN_ATTR_PWM), ADC_A3, PWM7, NOT_ON_TIMER},
  { PORT0,  6, PIO_DIGITAL, PIN_ATTR_DIGITAL, No_ADC_Channel, NOT_ON_PWM, NOT_ON_TIMER}, // INT3
  { PORT0,  7, PIO_DIGITAL, PIN_ATTR_DIGITAL, No_ADC_Channel, NOT_ON_PWM, NOT_ON_TIMER}, // INT4
  { PORT0,  8, PIO_DIGITAL, (PIN_ATTR_DIGITAL|PIN_ATTR_PWM), No_ADC_Channel, PWM10, NOT_ON_TIMER},    //USER_LED
  { PORT0,  9, PIO_DIGITAL, PIN_ATTR_DIGITAL, No_ADC_Channel, NOT_ON_PWM, NOT_ON_TIMER}, // NFC1
  { PORT0, 10, PIO_DIGITAL, PIN_ATTR_DIGITAL, No_ADC_Channel, NOT_ON_PWM, NOT_ON_TIMER}, // NFC2
  { PORT0, 11, PIO_DIGITAL, PIN_ATTR_DIGITAL, No_ADC_Channel, NOT_ON_PWM, NOT_ON_TIMER}, // TX
  { PORT0, 12, PIO_DIGITAL, PIN_ATTR_DIGITAL, No_ADC_Channel, NOT_ON_PWM, NOT_ON_TIMER}, // RX
  { PORT0, 13, PIO_DIGITAL, PIN_ATTR_DIGITAL, No_ADC_Channel, NOT_ON_PWM, NOT_ON_TIMER}, // SDA
  { PORT0, 14, PIO_DIGITAL, PIN_ATTR_DIGITAL, No_ADC_Channel, NOT_ON_PWM, NOT_ON_TIMER}, // SCL
  { PORT0, 15, PIO_DIGITAL, PIN_ATTR_DIGITAL, No_ADC_Channel, NOT_ON_PWM, NOT_ON_TIMER}, // SDA1
  { PORT0, 16, PIO_DIGITAL, PIN_ATTR_DIGITAL, No_ADC_Channel, NOT_ON_PWM, NOT_ON_TIMER}, // SCL1
  { PORT0, 17, PIO_DIGITAL, PIN_ATTR_DIGITAL, No_ADC_Channel, NOT_ON_PWM, NOT_ON_TIMER}, // TP4
  { PORT0, 18, PIO_DIGITAL, PIN_ATTR_DIGITAL, No_ADC_Channel, NOT_ON_PWM, NOT_ON_TIMER}, // TP5
  { PORT0, 19, PIO_DIGITAL, PIN_ATTR_DIGITAL, No_ADC_Channel, NOT_ON_PWM, NOT_ON_TIMER}, // INT2
  { PORT0, 20, PIO_DIGITAL, PIN_ATTR_DIGITAL, No_ADC_Channel, NOT_ON_PWM, NOT_ON_TIMER}, // INT1
  { PORT0, 21, PIO_DIGITAL, PIN_ATTR_DIGITAL, No_ADC_Channel, NOT_ON_PWM, NOT_ON_TIMER}, // INT1
  { PORT0, 22, PIO_DIGITAL, (PIN_ATTR_DIGITAL|PIN_ATTR_PWM), No_ADC_Channel, PWM9, NOT_ON_TIMER},
  { PORT0, 23, PIO_DIGITAL, (PIN_ATTR_DIGITAL|PIN_ATTR_PWM), No_ADC_Channel, PWM8, NOT_ON_TIMER},
  { PORT0, 24, PIO_DIGITAL, PIN_ATTR_DIGITAL, No_ADC_Channel, NOT_ON_PWM, NOT_ON_TIMER}, // INT
  { PORT0, 25, PIO_DIGITAL, (PIN_ATTR_DIGITAL|PIN_ATTR_PWM), No_ADC_Channel, PWM11, NOT_ON_TIMER},   //RED_LED
  { PORT0, 26, PIO_DIGITAL, (PIN_ATTR_DIGITAL|PIN_ATTR_PWM), No_ADC_Channel, PWM11, NOT_ON_TIMER},  //GREEN_LED
  { PORT0, 27, PIO_DIGITAL, (PIN_ATTR_DIGITAL|PIN_ATTR_PWM), No_ADC_Channel, PWM11, NOT_ON_TIMER},  //BLUE_LED
  { PORT0, 28, PIO_DIGITAL, (PIN_ATTR_DIGITAL|PIN_ATTR_PWM), ADC_A4, PWM3, NOT_ON_TIMER},
  { PORT0, 29, PIO_DIGITAL, (PIN_ATTR_DIGITAL|PIN_ATTR_PWM), ADC_A5, PWM2, NOT_ON_TIMER},
  { PORT0, 30, PIO_DIGITAL, (PIN_ATTR_DIGITAL|PIN_ATTR_PWM), ADC_A6, PWM1, NOT_ON_TIMER},
  { PORT0, 31, PIO_DIGITAL, (PIN_ATTR_DIGITAL|PIN_ATTR_PWM), ADC_A7, PWM0, NOT_ON_TIMER}
};

// Don't remove this line
#include <compat_pin_mapping.h>

#endif

/*
  If you don't use an nRF5 board, you can ignore this file.

  This file was part of the "My Sensors nRF5 Boards" board repository
  available at https://github.com/mysensors/ArduinoBoards If you have
  questions, please refer the documentation at
  https://github.com/mysensors/ArduinoHwNRF5 first.

  This file is compatible with ArduinoHwNRF5 >= 0.2.0

  This file allows you to change the pins of internal hardware, like the
  serial port, SPI bus or Wire bus.

  All pins referenced here are mapped via the "g_ADigitalPinMap" Array
  defined in "MyBoardNRF5.cpp" to pins of the MCU.
  
  As an example, if you have at the third position in "g_ADigitalPinMap" the
  12, then all ports referenced in Arduino with 2 are mapped to P0.12. If you
  don't change the "g_ADigitalPinMap" Array, the Arduino pins 0..31 are
  translated to P0.00..P0..31.
   
  ###########################################################################
 
  This file is compatible with ArduinoHwNRF5 > 0.1.0
  Copyright (c) 2014-2015 Arduino LLC.  All right reserved.
  Copyright (c) 2016 Sandeep Mistry. All right reserved.
  Copyright (c) 2017 Sensnology AB. All right reserved.

  This library is free software; you can redistribute it and/or
  modify it under the terms of the GNU Lesser General Public
  License as published by the Free Software Foundation; either
  version 2.1 of the License, or (at your option) any later version.
  This library is distributed in the hope that it will be useful,
  but WITHOUT ANY WARRANTY; without even the implied warranty of
  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
  See the GNU Lesser General Public License for more details.
  You should have received a copy of the GNU Lesser General Public
  License along with this library; if not, write to the Free Software
  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
*/

#ifndef _MYBOARDNRF5_H_
#define _MYBOARDNRF5_H_

#ifdef __cplusplus
extern "C"
{
#endif // __cplusplus

// Number of pins defined in PinDescription array
#define PINS_COUNT           (32u)
#define NUM_DIGITAL_PINS     (32u)
#define NUM_ANALOG_INPUTS    (8u)
#define NUM_ANALOG_OUTPUTS   (8u)

/* 
 *  LEDs
 *  
 *  This is optional
 *  
 *  With My Sensors, you can use
 *  hwPinMode() instead of pinMode()
 *  hwPinMode() allows to use advanced modes like OUTPUT_H0H1 to drive LEDs.
 *  https://github.com/mysensors/MySensors/blob/development/drivers/NRF5/nrf5_wiring_constants.h
 *
 */
#define PIN_LED1                (8)
// #define PIN_LED2                (25)
// #define PIN_LED3                (26)
// #define PIN_LED4                (27)
// #define PIN_LED5                (12)
// #define PIN_LED6                (14)
// #define PIN_LED7                (15)
// #define PIN_LED8                (16)
// #define USER_LED             	 (PIN_LED2)
// #define RED_LED                 (PIN_LED3)
// #define GREEN_LED            	 (PIN_LED4)
// #define BLUE_LED			           (PIN_LED1)
// #define BLE_LED                 BLUE_LED
#define LED_BUILTIN          PIN_LED1

/* 
 *  Buttons
 *  
 *  This is optional
 */
// #define PIN_BUTTON1             (3)
// #define PIN_BUTTON2             (4)
// #define PIN_BUTTON3             (5)
// #define PIN_BUTTON4             (6)
// #define PIN_BUTTON5             (7)
// #define PIN_BUTTON6             (8)
// #define PIN_BUTTON7             (9)
// #define PIN_BUTTON8             (10)

/* 
 * Analog ports
 *  
 * If you change g_APinDescription, replace PIN_AIN0 with
 * port numbers mapped by the g_APinDescription Array.
 * You can add PIN_AIN0 to the g_APinDescription Array if
 * you want provide analog ports MCU independed, you can add
 * PIN_AIN0..PIN_AIN7 to your custom g_APinDescription Array
 * defined in MyBoardNRF5.cpp
 */
static const uint8_t A0  = ADC_A0;
static const uint8_t A1  = ADC_A1;
static const uint8_t A2  = ADC_A2;
static const uint8_t A3  = ADC_A3;
static const uint8_t A4  = ADC_A4;
static const uint8_t A5  = ADC_A5;
static const uint8_t A6  = ADC_A6;
static const uint8_t A7  = ADC_A7;

/*
 * Serial interfaces
 * 
 * RX and TX are required.
 * If you have no serial port, use unused pins
 * CTS and RTS are optional.
 */
 /*
#define PIN_SERIAL_RX       (12)
#define PIN_SERIAL_TX       (11) 
*/
// I changed this....
#define PIN_SERIAL_RX       (13)
#define PIN_SERIAL_TX       (14)
// #define PIN_SERIAL_CTS      (13)
// #define PIN_SERIAL_RTS      (14)

/*
 * SPI Interfaces
 * 
 * This is optional
 * 
 * If SPI is defined MISO, MOSI, SCK are required
 * SS is optional and can be used in your sketch.
 */
#define SPI_INTERFACES_COUNT 1

#define PIN_SPI_MISO         (2)
#define PIN_SPI_MOSI         (3)
#define PIN_SPI_SCK          (4)
#define PIN_SPI_SS           (5)

static const uint8_t SS   = PIN_SPI_SS;
static const uint8_t MOSI = PIN_SPI_MOSI;
static const uint8_t MISO = PIN_SPI_MISO;
static const uint8_t SCK  = PIN_SPI_SCK;

/*
 * Wire Interfaces
 *
 * This is optional
 */
#define WIRE_INTERFACES_COUNT 2

#define PIN_WIRE_SDA         (13u)
#define PIN_WIRE_SCL         (14u)

#define PIN_WIRE_SDA1        (15u)
#define PIN_WIRE_SCL1        (16u)

static const uint8_t SDA = PIN_WIRE_SDA;
static const uint8_t SCL = PIN_WIRE_SCL;

#ifdef __cplusplus
}
#endif

#endif

[ileneken3]

@ileneken3
OK, I fixed one layer of the problem! I removed the JLINK driver using Device Manager, then re-installed using Zadig. Now the Arduino IDE tells me it is programmed without a problem.
But the next layer of the problem still exists, the programmed board doesn't seem to send anything to the gateway. I am monitoring this from the logs of mysgw, and from Domoticz. I am expecting the gateway to see something from the node, at least the registration.

Thanks again

[Omemanti]

@ileneken3 Have you considered building a new gateway with a nrf52?
You know now that the IDE is programming correctly. Try combining a ftdi and nrf52 to get a serial gateway.

Also I would hook up the gateway and prototype board to a serial monitor. ( So both boards onto my PC)
You can both monitor the node and the gateway directly from the RX and use https://www.mysensors.org/controller/myscontroller to act as controller.
I find it handy to cut out things like domoticz when troubleshooting (the less variables the better)

[ileneken3]

@omemanti
I was looking at the output of mysgw running on a Raspberry PI - so Domoticz is not really in the picture. But - your advise made me think I should try programming the chip on the development board directly before using an external one. And it works! I can see the registration of the Mysensors device.
So I guess everything is OK in terms of IDE and Mysensors code, and there must be something wrong with my external board. I will have to try a different one, and/or look over the soldering.

Happy Holidays!

[NeverDie]

Just paste your hex file to the JLINK drive that appears when you connect your DK. That will handle the upload for you. It's as simple as that.

[ileneken3]

@neverdie
Unfortunately, nothing is that simple - at least for me. I have gone in circles with the J-LINK drivers. In order to use the Arduino IDE for programming, you must use the WinUSB driver installed by Zadig. But if you do that, the nRFgo Studio no longer recognizes any J-LINK device. So I re-install RFgo Studio, and then I can't use the Arduino IDE anymore!

But I can work around those issues, because everything programs and works right when programming the device on the NRF DK board. The problem is I can't do anything with the two external boards I tried. With one, I was able to unlock it with a "Recover" in nRFgo Studio, but the programming doesn't seem to cause the chip to do anything (nothing logged by the gateway). With the other, I can't unlock the board - it always says: "Recover failed: Unknown error".
Both boards are E73 - but one is marked as E73-2G4M04S and the other is E73-2G4M04S1B.

Any ideas?

[Omemanti]

@ileneken3

the difference between E73-2G4M04S and E73-2G4M04S1B is that the last one seems to be from a new batch. I got both, the only difference was that the last one I needed to recover and the other one (old) I only had to "burn bootloader".

your problem with the Arduino IDE seems to have something to do with the Sandeep installation, see the comment of @Toyman: https://forum.mysensors.org/topic/6961/nrf5-action/1749

[NeverDie]

@ileneken3 What I meant was just export your .hex file and then drop it on the virtual JLINK drive to do the chip programming, not try to burn it directly from the IDE. That way you only depend on the DK doing it's job, not on an arduino IDE, where some versions don't seem to work well. Anyhow, that's how I do it now, and, at least for me, it seems to work the most reliably.

That said, I haven't tried the E73-2G4M04S1B, so can't really say regarding that one specifically. On the inside they should all be the same chip though, so I'm surprised to hear that it may have different requirements.

These days I'm largely focused on the nRF52840 and driving it with Forth. Maybe later I may circle back to the 832.

[ileneken3]

@neverdie

Yes, I understood what you meant. I will only do the "Export compiled Binary" from the IDE, and leave the drivers as J-Link commander or nrfGo Studio wants them.

In: https://www.openhardware.io/view/376/MySensors-NRF5-Platform it says:
"Currently, the nRF52832 and nRF51822 are supported so we recommend sticking with those for now."

I noticed that my board: (E73-2G4M04S) is labeled "NRF52810". So is that why after programming it nothing works (nothing seen on gateway) ?

If so, I messed up on that order.

But I am also trying the E73 2G4M04S1B, which at least from the AliExpress order
https://www.aliexpress.com/item/CDEBYTE-E73-2G4M04S-BLE-4-2-5-0-long-distance-100m-2-4GHz-SMD-ARM-Core/32820692238.html?spm=a2g0s.9042311.0.0.27424c4dSKBLn7

says it is nRF52832. (It isn't labeled on the board though). For this module, I can't unlock it using "Recover" from nRfgoStudio. It always fails with a message "Recover failed: Unknown error".

From the command line, if I do

nrfjprog.exe -f NRF52 --recover --log

and it comes back immediately with:

Recovering device. This operation might take 30s.
ERROR: Recover failed. Please make sure that the correct device family is given
ERROR: and try again.

The key error from the log seems to be:

2018-Dec-27 12:25:22 . . . . . nRF52_power_debug_and_system_regions
2018-Dec-27 12:25:22 . . . . . . nRF52_write_debug_port_register
2018-Dec-27 12:25:22 . . . . . . nRF52_write_debug_port_register: JLink: JLINK_CORESIGHT_WriteAPDPReg(DP reg 0x02, 0x00000000)
2018-Dec-27 12:25:22 . . . . . . nRF52_write_debug_port_register: JLink: returns -1
2018-Dec-27 12:25:23 . . . . . . nRF52_write_debug_port_register: JLink: (0005ms, 0288ms total)
2018-Dec-27 12:25:23 . . . . . . nRF52_write_debug_port_register: JLinkARM.dll CORESIGHT_WriteAPDPReg returned error -1.

2018-Dec-27 12:25:23 . . . . . nRF52_power_debug_and_system_regions: JLinkARM.dll CORESIGHT_WriteAPDPReg returned error -102.

If I do: nrfjprog.exe -f NRF51 --recover --log

it actually makes LD5 on the DK board flash for 30 seconds, but still returns failure with the exact same message.

Any other tricks for "recover/unlock" of those boards?

Thanks!

[NeverDie]

@ileneken3 I suggest posting a query on the nordic devzone forum. A Nordic engineer will get assigned to it and give you an answer. I've tried this a few times, and I had good luck with it. Generally 24 hour turnaround on weekdays, and no answers on weekends. So, if you post it now, you may get an answer tomorrow. It's in Nordic's interest to help developers unlock these chips, and if there are any secrets to doing so, Nordic will certainly know them.

It sounds as though once you get past the unlock issue, it will be easier for you.

[Omemanti]

@ileneken3 sorry, can't help you anymore.

I can only tell that I installed the segger drivers, and everything as described by @d00616

Most issues I have, happen when I did some soldering wrong or when I've been messing around with drivers. A clean setup almost always solve my problems

I used both old and new ebyte modules and they work like a charm.

[Sancho119]

Hi,

I'm trying to begin with nrf52832.
I have follow advice, with soldering 4 wires. I use STlink v2, downloading soft before use it.
When i try to erase the nrf52832, with sketch "mass_erase" in exemple, i have the following error :

Arduino : 1.8.7 (Windows 10), Carte : "MyBoardNRF5 nRF52832, None, Crystal Oscillator, Don't enable"

C:\Users\Sancho\AppData\Local\Arduino15\packages\sandeepmistry\tools\openocd\0.10.0-dev.nrf5/bin/openocd.exe -d2 -f interface/stlink-v2.cfg -c transport select hla_swd; set WORKAREASIZE 0x4000; -f target/nrf52.cfg -c init; halt; nrf51 mass_erase; program {{{build.core.path}/SDK/components/softdevice/none/hex/none_nrf52_{softdeviceversion}_softdevice.hex}} verify reset; shutdown;
Open On-Chip Debugger 0.10.0-dev-00254-g696fc0a (2016-04-10-10:13)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
debug_level: 2
0x4000
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 10000 kHz
Info : Unable to match requested speed 10000 kHz, using 4000 kHz
Info : Unable to match requested speed 10000 kHz, using 4000 kHz
Info : clock speed 4000 kHz
Info : STLINK v2 JTAG v29 API v2 SWIM v7 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.280426
Error: init mode failed (unable to connect to the target)
in procedure 'init'
in procedure 'ocd_bouncer'

Erreur lors de la gravure de la séquence d'initialisation.

I try to upload an empty sketch (MyBoardNRF5), and have this message :

Arduino : 1.8.7 (Windows 10), Carte : "MyBoardNRF5 nRF52832, None, Crystal Oscillator, Don't enable"

Le croquis utilise 10508 octets (2%) de l'espace de stockage de programmes. Le maximum est de 524288 octets.
C:\Users\Sancho\AppData\Local\Arduino15\packages\sandeepmistry\tools\openocd\0.10.0-dev.nrf5/bin/openocd.exe -d2 -f interface/stlink-v2.cfg -c transport select hla_swd; set WORKAREASIZE 0x4000; -f target/nrf52.cfg -c program {{C:\Users\Sancho\AppData\Local\Temp\arduino_build_74329/MyBoardNRF5.ino.hex}} verify reset; shutdown;
Open On-Chip Debugger 0.10.0-dev-00254-g696fc0a (2016-04-10-10:13)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
debug_level: 2
0x4000
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 10000 kHz
Une erreur est survenue lors du transfert du croquis
Info : Unable to match requested speed 10000 kHz, using 4000 kHz
Info : Unable to match requested speed 10000 kHz, using 4000 kHz
Info : clock speed 4000 kHz
Info : STLINK v2 JTAG v29 API v2 SWIM v7 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.280426
Error: init mode failed (unable to connect to the target)
in procedure 'program'
in procedure 'init' called at file "embedded:startup.tcl", line 473
in procedure 'ocd_bouncer'
** OpenOCD init failed **
shutdown command invoked

Can you help me please ?

[monte]

@sancho119 what exact model of a board do you have? Did you try to switch SWDIO and SWCLK, maybe they are messed up? Or lose connection? To erase softdevice you can simply chose Tools>Softdevice>"None" and then press "Burn bootloader" button.

[Sancho119]

Hello
it's a E73 2G4M04S1B from EBYTE
When i switch SWDIO and SWCLK, i can see the led of STLink V2 changing from red to blue, but when i try to uplod empty sketch (MyBoardNRF5), i have this error :

C:\Users\Sancho\AppData\Local\Arduino15\packages\sandeepmistry\tools\openocd\0.10.0-dev.nrf5/bin/openocd.exe -d2 -f interface/stlink-v2.cfg -c transport select hla_swd; set WORKAREASIZE 0x4000; -f target/nrf52.cfg -c program {{C:\Users\Sancho\AppData\Local\Temp\arduino_build_432557/MyBoardNRF5.ino.hex}} verify reset; shutdown;
Open On-Chip Debugger 0.10.0-dev-00254-g696fc0a (2016-04-10-10:13)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
debug_level: 2
0x4000
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 10000 kHz
Info : Unable to match requested speed 10000 kHz, using 4000 kHz
Info : Unable to match requested speed 10000 kHz, using 4000 kHz
Info : clock speed 4000 kHz
Info : STLINK v2 JTAG v29 API v2 SWIM v7 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.283200
Info : nrf52.cpu: hardware has 0 breakpoints, 2 watchpoints
Error: timed out while waiting for target halted
TARGET: nrf52.cpu - Not halted
in procedure 'program'
in procedure 'reset' called at file "embedded:startup.tcl", line 478
in procedure 'ocd_bouncer'

embedded:startup.tcl:454: Error: ** Unable to reset target **
in procedure 'program'
in procedure 'program_error' called at file "embedded:startup.tcl", line 479
at file "embedded:startup.tcl", line 454
le port série sélectionné at file "embedded:startup.tcl", line 454
n'existe pas ou votre Arduino n'est pas connectée

[ncollins]

@sancho119 No matter what I tried, I could not unlock the E73 with the STLink.

I had to buy a jlink clone, download a bunch of segger debugging tools, use the segger tools to override the lock flag. After that I could flash the bootloader.

https://github.com/micooke/arduino-nRF5-smartwatches/blob/master/nrf52_disable_read_protection.txt

#To share my experience with the nRF52832.
#I was unable to disable the read protection / flash lock with a BMP or ST-Link V2, but i was successful with a J-Link.

#When nRF52832 chip is read protected / locked, the first step is to try:
nrfjprog –recover -f nrf52

#This performs the same task as:
Jlink -if swd -device nrf52
J-Link>SWDSelect
J-Link>SWDWriteDP 1, 0x50000000
J-Link>SWDWriteDP 2, 0x01000000
J-Link>SWDWriteAP 1, 0x00000001

#Wait until AP 2 is 0, and the operation is complete
J-Link>SWDReadAP 2

#If two successive reads from AP 3 produce 0, then 1 then protection is disabled
J-Link>SWDReadAP 3
J-Link>SWDReadAP 3

#Tested with JLink v6.20b

[monte]

@ncollins have you tried this: https://github.com/AndruPol/nrf52832-recover ?

[ncollins]

At the time, I did not have a BMP or any STM32 capable of being flashed as a programmer.

I figured the jlink clone might be useful in the future, but I definitely think the BMP / diy programmer is the way I would have gone if I had one sitting around.

[Sancho119]

@ncollins
@monte
thx for these advices.
I think i will try with BMP clone (STM32F103C8T6), cheaper than J-link (i must only wait 1 month to have it, buying it in china...)
is it possible to erase E73 with BMP in win10 ?

[berkseo]

https://translate.google.ru/translate?sl=auto&tl=en&u=http%3A%2F%2Fmysensors.ru%2Fforum%2Fviewtopic.php%3Ff%3D5%26t%3D456

https://www.nordicsemi.com/Software-and-Tools/Development-Tools/nRFgo-Studio/Download#infotabs

[Sancho119]

Hello,

Some news !
i buy a Jlink, and success in erase my nrf52832 with nrf prog, using method of berkseo.

Next i try to upload a basic sketch (blink) :

#define MY_RADIO_NRF5_ESB
#include <nrf.h>
#include <MySensors.h>

void setup() {
Serial.begin(9600);
hwPinMode(LED_BUILTIN,OUTPUT_H0H1);
}

void loop() {
digitalWrite(LED_BUILTIN, HIGH); // turn the LED on (HIGH is the voltage level)
delay(1000); // wait for a second
digitalWrite(LED_BUILTIN, LOW); // turn the LED off by making the voltage LOW
delay(1000); // wait for a second
}

I have this :

Open On-Chip Debugger 0.10.0-dev-00254-g696fc0a (2016-04-10-10:13)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
debug_level: 2
0
adapter speed: 10000 kHz
cortex_m reset_config sysresetreq
Info : No device selected, using first device.
Info : J-Link ARM-OB STM32 compiled Aug 22 2012 19:52:04
Info : Hardware version: 7.00
Info : VTarget = 3.300 V
Info : clock speed 10000 kHz
Info : SWD IDCODE 0x2ba01477
Info : nrf52.cpu: hardware has 6 breakpoints, 4 watchpoints
nrf52.cpu: target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0000051c msp: 0x20010000
** Programming Started **
auto erase enabled
Warn : Unknown device (HWID 0x00000139)
Warn : not enough working area available(requested 32)
Warn : no working area available, falling back to slow memory writes
wrote 12288 bytes from file C:\Users\Sancho\AppData\Local\Temp\arduino_build_76789/NRF5_blink_led8.ino.hex in 4.155332s (2.888 KiB/s)
** Programming Finished **
** Verify Started **
Warn : not enough working area available(requested 52)
verified 10812 bytes in 0.165932s (63.632 KiB/s)
** Verified OK **
** Resetting Target **
shutdown command invoked

I think its good, but when i put a led with a resistance on P0.08, nothing

could you help me more ?

[Toyman]

@sancho119 said in GUIDE - NRF5 / NRF51 / NRF52 for beginners:

Hello,

Some news !
i buy a Jlink, and success in erase my nrf52832 with nrf prog, using method of berkseo.

Next i try to upload a basic sketch (blink) :

#define MY_RADIO_NRF5_ESB
#include <nrf.h>
#include <MySensors.h>

void setup() {
Serial.begin(9600);
hwPinMode(LED_BUILTIN,OUTPUT_H0H1);
}

void loop() {
digitalWrite(LED_BUILTIN, HIGH); // turn the LED on (HIGH is the voltage level)
delay(1000); // wait for a second
digitalWrite(LED_BUILTIN, LOW); // turn the LED off by making the voltage LOW
delay(1000); // wait for a second
}

I have this :

Open On-Chip Debugger 0.10.0-dev-00254-g696fc0a (2016-04-10-10:13)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
debug_level: 2
0
adapter speed: 10000 kHz
cortex_m reset_config sysresetreq
Info : No device selected, using first device.
Info : J-Link ARM-OB STM32 compiled Aug 22 2012 19:52:04
Info : Hardware version: 7.00
Info : VTarget = 3.300 V
Info : clock speed 10000 kHz
Info : SWD IDCODE 0x2ba01477
Info : nrf52.cpu: hardware has 6 breakpoints, 4 watchpoints
nrf52.cpu: target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0000051c msp: 0x20010000
** Programming Started **
auto erase enabled
Warn : Unknown device (HWID 0x00000139)
Warn : not enough working area available(requested 32)
Warn : no working area available, falling back to slow memory writes
wrote 12288 bytes from file C:\Users\Sancho\AppData\Local\Temp\arduino_build_76789/NRF5_blink_led8.ino.hex in 4.155332s (2.888 KiB/s)
** Programming Finished **
** Verify Started **
Warn : not enough working area available(requested 52)
verified 10812 bytes in 0.165932s (63.632 KiB/s)
** Verified OK **
** Resetting Target **
shutdown command invoked

I think its good, but when i put a led with a resistance on P0.08, nothing

could you help me more ?

LED_BUILTIN corresponds to po17

[p359]

Hi. Are the steps in first post still valid please?

I'm trying without luck to get first nrf52 programmed. I get a weird error"Error resolving FQBN: missing" in Arduino IDE when I try to verify any basic sketch, even blink. Thanks for any thoughts

[ncollins]

@p359 Which version of Arduino IDE are you using? I was seeing that with 1.8.10, but I ended up downgrading to 1.8.6 to test and it worked.

[p359]

@ncollins 1.8.10 also. I'll try then 1.8.6 tonight. Cheers for the idea!

[MartinC]

Hi,

Is it possible to get Serial output in Arduino IDE for nRF52 boards with J-Link OB 7.0? Or do I need a newer programmer? Or maybe I can get it with ST-Link v2/v2.1 somehow?

[alowhum]

@martinc said in GUIDE - NRF5 / NRF51 / NRF52 for beginners:

Hi,

Is it possible to get Serial output in Arduino IDE for nRF52 boards with J-Link OB 7.0? Or do I need a newer programmer? Or maybe I can get it with ST-Link v2/v2.1 somehow?

The answer is actually in the first post.

[MartinC]

@alowhum said in GUIDE - NRF5 / NRF51 / NRF52 for beginners:

The answer is actually in the first post.

Thanks, I've seen it before. In my case a programmer is easier solution - I don't know yet how to re-assign TX&RX pins in Arduino on my EByte 52840 module and in specs for that module there is no info about UART connectivity.
Maybe you know how can I re-assign TX&RX pins in Arduino? Then I can solder wires to assigned TX&RX pins and connect them to USB-UART. What I've found is in Forth language ...

[idanronen]

Does anyone know what settings I need to use for this development board with arduino ide?
Ebyte E104-BT5032A-TB
https://a.aliexpress.com/_dT5dMb8

It has a cp2102 on board which I have the driver for. I've installed the arduino ide nrf52 board, but I can't find a programmer, board, or any other settings which will let me flash it without a Java exception or a timeout. Maybe I need to set the jumpers differently but there's no documentation on that.
OTA works fine though.

[Nca78]

@idanronen this is a UART to BT module, and from what I understand in the documentation the CP2102 is only here to give you access to the serial port of the module, but not to program it ?

To program it you will have to use the SWDIO/SWDCLK pins I suppose, and I'm interested to know if it can be reprogrammed because that would make a tiny NRF52832 module for boards that don't require many IOs.

[idanronen]

@Nca78 I feared that might be the case. my task for today was to dig up my st-link and try that, though I hoped I might have done something wrong and the cp2102 can be used to program and not just debug.
That module is pretty cheap and from what I see with the naked eye, you can disconnect the cp2102 with the jumpers so the power consumption might actually be good enough to use as-is.
I'll report back to let you know once I've succeeded

[Avamander]

I tried flashing MySensors onto my nRF52840 Adafruit Feather board but it fails, I opened an issue on GH about it https://github.com/mysensors/MySensors/issues/1424, maybe someone here has any ideas how to get it running on those boards?

[idanronen]

@Nca78 no luck with the st-link v2, though i doubt it is related to the board, but rather my inability. i've tried every option in zadig, installed the st-link driver from their website, and nothing works.
i get this in arduino ide:

debug_level: 0
0x4000
adapter speed: 10000 kHz
Error: init mode failed (unable to connect to the target)
in procedure 'program' 
in procedure 'init' called at file "embedded:startup.tcl", line 473
in procedure 'ocd_bouncer'
** OpenOCD init failed **
shutdown command invoked

the selected serial port 
 does not exist or your board is not connected

[ncollins]

With all the NRF52 modules from EBYTE I've tried, the only way I can flash them is over SWDIO, SWCLK, GND, VCC via JLink clone.

And, before flashing is possible, I have to unlock the module by following these directions: https://github.com/micooke/arduino-nRF5-smartwatches/blob/master/nrf52_disable_read_protection.txt

[idanronen]

@ncollins I've been working on turning an stm32f030f4p6 into a blackmagic probe for a few days now. Hit a wall when the compiled firmware came out to 83kb which is over the 64kb on board. Found someone who shrunk it down so it'd fit, and someone claiming it has another 64kb which can be unlocked. I'm just looking for the patience to get back in there, as this whole thing has been a major ordeal

[idanronen]

Im not sure my flashing with the blackmagic even does anything. The console is unclear:

Sketch uses 3556 bytes (0%) of program storage space. Maximum is 409600 bytes.
Remote debugging using \\.\COM11
Target voltage: ABSENT!
Available Targets:
No. Att Driver
 1      Nordic nRF52 M3/M4
 2      Nordic nRF52 Access Port 
Attaching to Remote target
0xfffffffe in ?? ()
Reading symbols from nrf1.ino.elf...done.
Loading section .text, size 0xde4 lma 0x1c000
Loading section .ARM.exidx, size 0x8 lma 0x1cde4
Loading section .data, size 0x78 lma 0x1cdec
Start address 0x1c578, load size 3684
Transfer rate: 33 KB/sec, 614 bytes/write.
Temporary breakpoint 1 at 0x1cb8c: file C:\Users\....\AppData\Local\Arduino15\packages\sandeepmistry\hardware\nRF5\0.6.0\cores\nRF5\main.cpp, line 28.
Starting program: C:\Users\....\AppData\Local\Temp\arduino_build_366086\nrf1.ino.elf 
Note: automatically using hardware breakpoints for read-only addresses.

Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()

Program complete!

and i dont see any serial debug information

[BearWithBeard]

I just got my first NRF5 running. I'll note how I got it working in case any of you guys still have troubles:

Setup

• OS: Windows 10
• Programmer: STM32 Blue Pill with the Black Magic Probe firmware
• NRF5: EByte E73-TBB dev board with a E73-2G4M0S1B (NRF52832)
• Environment: PlatformIO

Instructions

Load the Black Magic Probe firmware with stlink as the probe host onto Blue Pill. You can follow this guide.

Connect your new BMP to the NRF52 module:

BMP	NRF52	Serial Port
3V3	3V3
GND	GND
A5	SWDCLK	GDB Server
B14	SWDIO	GBD Server
A2	RXI	UART
A3	TXO	UART

Note: A2 and A3 are not required for programming. This is how you'd wire up the BMP for "classic" serial debugging. You can use the BMP both for programming and serial communication - no need for a second FTDI module.

Using the GNU Arm Embedded Toolchain, run arm-none-eabi-gdb in a console and enter the following commands to unlock the NRF52:

target extended-remote BMP_GDB_SERVER_PORT
mon swdp_scan
attach N // N = number of "Nordic nRF52 Access Port" if there are several
mon erase_mass
detach

From the two serial ports the BMP provides, you want to use the GDB Server for BMP_GDB_SERVER_PORT above. If Windows only provides generic names for both ("USB Serial Device" or something), the one with the lower number should (usually) be the right choice. If not, try the other one.

Windows users also must prefix the port with \\.\ if the number is double-digit, e.g. \\.\COM13.

Now you can start uploading sketches the usual way. Here's my minimal PlatformIO config:

[env:nrf52_dk]
platform = nordicnrf52
board = nrf52_dk
board_build.variant = generic
framework = arduino
upload_protocol = blackmagic
lib_deps = 
	548 ; MySensors

And a minimal test sketch for MySensors:

#include <Arduino.h>

#define LED 17

#define MY_RADIO_RF24
#define MY_RADIO_NRF5_ESB
#define MY_NODE_ID 182

#define SKETCH_NAME "NRF52 Test"
#define SKETCH_VERSION "0.1"

#include <MySensors.h>

#define CHILD_ID 1
MyMessage msg(CHILD_ID, V_VAR1);

void presentation()
{
  sendSketchInfo(SKETCH_NAME, SKETCH_VERSION);
  present(CHILD_ID, S_CUSTOM);
}

void setup()
{
  pinMode(LED, OUTPUT);
}

void loop()
{
  static uint8_t num;
  send(msg.set(num));
  ++num;
  
  digitalWrite(LED, HIGH);
  wait(5000);
  digitalWrite(LED, LOW);
  wait(5000);
}

Works like a charm so far! Now, if you please excuse me, I have a whole new microprocessor family to explore. Fun times!

[nagelc]

@BearWithBeard said in GUIDE - NRF5 / NRF51 / NRF52 for beginners:

From the two ports the BMP provides, you want to use the GDB Server. If Windows only provides generic names for both ("USB Serial Device" or something), the one with the lower number should be the right choice.

Strangely, my BMP uses the higher port number as the GDB server and the lower one as the serial port. I think this is unusual since it is opposite of what most guides say to expect. So, try the higher one if the lower one doesn't work.

[Ikes 72000]

@BearWithBeard said in GUIDE - NRF5 / NRF51 / NRF52 for beginners:

I just got my first NRF5 running. I'll note how I got it working in case any of you guys still have troubles:

Setup

• OS: Windows 10
• Programmer: STM32 Blue Pill with the Black Magic Probe firmware
• NRF5: EByte E73-TBB dev board with a E73-2G4M0S1B (NRF52832)
• Environment: PlatformIO

Instructions

Load the Black Magic Probe firmware with stlink as the probe host onto Blue Pill. You can follow this guide.

Connect your new BMP to the NRF52 module:

BMP	NRF52	Serial Port
3V3	3V3
GND	GND
A5	SWDCLK	GDB Server
B14	SWDIO	GBD Server
A2	TX	UART
A3	RX	UART

Note: A2 and A3 are not required for programming. This is how you'd wire up the BMP for "classic" serial debugging. You can use the BMP both for programming and serial communication - no need for a second FTDI module.

Using the GNU Arm Embedded Toolchain, run arm-none-eabi-gdb in a console and enter the following commands to unlock the NRF52:

target extended-remote BMP_GDB_SERVER_PORT
mon swdp_scan
attach N // N = number of "Nordic nRF52 Access Port" if there are several
mon erase_mass
detach

From the two serial ports the BMP provides, you want to use the GDB Server for BMP_GDB_SERVER_PORT above. If Windows only provides generic names for both ("USB Serial Device" or something), the one with the lower number should (usually) be the right choice. If not, try the other one.

Windows users also must prefix the port with \\.\ if the number is double-digit, e.g. \\.\COM13.

Now you can start uploading sketches the usual way. Here's my minimal PlatformIO config:

[env:nrf52_dk]
platform = nordicnrf52
board = nrf52_dk
board_build.variant = generic
framework = arduino
upload_protocol = blackmagic
lib_deps = 
	548 ; MySensors

And a minimal test sketch for MySensors:

#include <Arduino.h>

#define LED 17

#define MY_RADIO_RF24
#define MY_RADIO_NRF5_ESB
#define MY_NODE_ID 182

#define SKETCH_NAME "NRF52 Test"
#define SKETCH_VERSION "0.1"

#include <MySensors.h>

#define CHILD_ID 1
MyMessage msg(CHILD_ID, V_VAR1);

void presentation()
{
  sendSketchInfo(SKETCH_NAME, SKETCH_VERSION);
  present(CHILD_ID, S_CUSTOM);
}

void setup()
{
  pinMode(LED, OUTPUT);
}

void loop()
{
  static uint8_t num;
  send(msg.set(num));
  ++num;
  
  digitalWrite(LED, HIGH);
  wait(5000);
  digitalWrite(LED, LOW);
  wait(5000);
}

Works like a charm so far! Now, if you please excuse me, I have a whole new microprocessor family to explore. Fun times!

@BearWithBeard just thanks, this method just work fine.
But just need to use the hightest port number of the BMP.

[Nca78]

@idanronen said in GUIDE - NRF5 / NRF51 / NRF52 for beginners:

Does anyone know what settings I need to use for this development board with arduino ide?
Ebyte E104-BT5032A-TB
https://a.aliexpress.com/_dT5dMb8

It has a cp2102 on board which I have the driver for. I've installed the arduino ide nrf52 board, but I can't find a programmer, board, or any other settings which will let me flash it without a Java exception or a timeout. Maybe I need to set the jumpers differently but there's no documentation on that.
OTA works fine though.

So, I have finally received mines, and I can program the SoftDevice on them using NRF52 DK and nRF Go Studio. The first time it tells be there is a readback protection and offers a "Recover" option that erases the chip and allows to use it as normal.
Now I'll try to see what IOs the MOD, WKP, DISC, LINK, DATA, RX, TX, RTS, CTS pins are connected to and that will make a nice little module for modules with limited space and low io pins requirements.
Great replacement for NRF51822-04 imho: similar surface, better chip, more IOs and similar low price.

[idanronen]

@BearWithBeard said in GUIDE - NRF5 / NRF51 / NRF52 for beginners:

I just got my first NRF5 running. I'll note how I got it working in case any of you guys still have troubles:

Setup

• OS: Windows 10
• Programmer: STM32 Blue Pill with the Black Magic Probe firmware
• NRF5: EByte E73-TBB dev board with a E73-2G4M0S1B (NRF52832)
• Environment: PlatformIO

Instructions

Load the Black Magic Probe firmware with stlink as the probe host onto Blue Pill. You can follow this guide.

Connect your new BMP to the NRF52 module:

BMP	NRF52	Serial Port
3V3	3V3
GND	GND
A5	SWDCLK	GDB Server
B14	SWDIO	GBD Server
A2	TX	UART
A3	RX	UART

Note: A2 and A3 are not required for programming. This is how you'd wire up the BMP for "classic" serial debugging. You can use the BMP both for programming and serial communication - no need for a second FTDI module.

Using the GNU Arm Embedded Toolchain, run arm-none-eabi-gdb in a console and enter the following commands to unlock the NRF52:

target extended-remote BMP_GDB_SERVER_PORT
mon swdp_scan
attach N // N = number of "Nordic nRF52 Access Port" if there are several
mon erase_mass
detach

From the two serial ports the BMP provides, you want to use the GDB Server for BMP_GDB_SERVER_PORT above. If Windows only provides generic names for both ("USB Serial Device" or something), the one with the lower number should (usually) be the right choice. If not, try the other one.

Windows users also must prefix the port with \\.\ if the number is double-digit, e.g. \\.\COM13.

Now you can start uploading sketches the usual way. Here's my minimal PlatformIO config:

[env:nrf52_dk]
platform = nordicnrf52
board = nrf52_dk
board_build.variant = generic
framework = arduino
upload_protocol = blackmagic
lib_deps = 
	548 ; MySensors

And a minimal test sketch for MySensors:

#include <Arduino.h>

#define LED 17

#define MY_RADIO_RF24
#define MY_RADIO_NRF5_ESB
#define MY_NODE_ID 182

#define SKETCH_NAME "NRF52 Test"
#define SKETCH_VERSION "0.1"

#include <MySensors.h>

#define CHILD_ID 1
MyMessage msg(CHILD_ID, V_VAR1);

void presentation()
{
  sendSketchInfo(SKETCH_NAME, SKETCH_VERSION);
  present(CHILD_ID, S_CUSTOM);
}

void setup()
{
  pinMode(LED, OUTPUT);
}

void loop()
{
  static uint8_t num;
  send(msg.set(num));
  ++num;
  
  digitalWrite(LED, HIGH);
  wait(5000);
  digitalWrite(LED, LOW);
  wait(5000);
}

Works like a charm so far! Now, if you please excuse me, I have a whole new microprocessor family to explore. Fun times!

For the life of me i cant figure out if im making the BlackMagic properly. I'm moving the boot0 jumper to 1, flashing the 8kb maple (usb flash) DFU file using the st-link application on windows.
I move the jumper back to 0, and connect using the micro usb, and i can flash code normally using arudino IDE using the STM32duino bootloader (and if i do so, i see the device communication on a new COM port).
From there i cant get anything from these guides to work. the windows STM "flash demonstrator" app doesnt recognize the device, and i dont have a linux machine available at the moment for the dfu-util (and Ubuntu shell on windows wont recognize the usb device). When i try to flash the blackmagic.bin starting at 0x08002000 using the ST-link software it shows it succeeded, but when i return the jumper to 0 and reset the device, this is what i get:

The 2 new COM ports appear (COM12,COM13), but i cant seem to flash anything successfully.
I've installed the GNU arm toolchain for windows and tried "target extended-remote \.\COM13" (12 just gets stuck on nothing), and i get:

[novicit]

@idanronen , I am not an expert but did manage to accomplish what you are doing about a year ago. I can tell you that you are supposed to get two com ports from BMP. Also, where your screen shot says "SW-DP scan failed" means BMP cannot find any 'targets' on the nrf52. You should get back something that looks like this from the scan:
Available Targets:
No. Att Driver
1 ARM Cortex-M
2 Nordic nRF52 Access Port

I performed this operation on ~10 nrf52832 and only one failed the scan. I never found out how to solve it.

Also, your use of the attach command is incorrect. You appear to be trying to attach the com port 13. If the swdp_scan had worked corrrectly, you would then attach the target that shows up in the scan. In my example output, it would be "attach 2" - the nRF52 Access Port.

That adds what I know, hope it helps a bit.

[electrik]

Hello, I'm using MySensors for some years now and after using the NRF24 and recently the RFM69 I want to explore the NRF5 platform.
My idea is to use a NRF52840 as gateway, and NRF52832 as nodes. So I am making a list so I can get started, but was wondering what else I should order besides the NRF5's?
I read a programmer is required, for example. What is your experience or advice for this? A ST-link or J-link? Could you share your experiences?
Thanks
Rik

[ncollins]

@electrik I believe NRF52832 and 51822 are the only supported NRF modules at this time. Some people have experimented and modified dependent libraries to get NRF52840 to work with MySensors but I'm not sure it's completely working and definitely wouldn't start there.

Personally, I like using the Ebyte NRF24 PA+LNA modules for my gateways and repeaters and use the NRF5 modules for end nodes.

I'm not even sure you can use NRF5 as a radio for a gateway, if so it might only work as a serial gateway.

As for additional items, I bought a jlink clone after having trouble unlocking ebyte modules with a STLink. Then my jlink clone caused issues (old firmware, not updatable) so I ended up buying a real JLink-edu.

Other things worth noting: there are a surprising number of hardware bugs with the NRF chips that mostly result in higher power consumption. General advice would be to stay away from NRF51822. EBYTE modules have been consistently reliable, high quality.

[Puneit Thukral]

@ncollins It is possible to use NRF51822 for gateways with serial. I am using it for many months now. We need USB to serial adapter.
Also, I do not use JLink or ST-Link for flashing the NRF51 chips. I use raspberry pi with OpenOCD.
OpenOCD setup can be overwhelming (it was for me) but I have been able to make it work and replicate for a while now. If someone needs inputs, I am happy to help. Ask here or reach out to me on discord @ Puneit#2433

For the very reason you stated - hardware bugs in NR51 chips leading to high power-consumption - they make compact repeater nodes / powered nodes with repeaters.

[monte]

Mentioned hardware bugs are easily omitted by using custom sleep function.

[Puneit Thukral]

@monte Could you please share the custom sleep function?

[monte]

@Puneit-Thukral you can start looking from here https://forum.mysensors.org/post/92044

[electrik]

Is it possible to use such a ready made device, and reprogram it with a mysensors sketch?

https://a.aliexpress.com/_v4kOXD

[monte]

@electrik yes. You will need an SWD programmer, J-link, ST-link or black magic probe will do. But the thing, you've linked isn't NRF5 device. So if you are asking about exactly that device, then answer is no. Only Nordic bluetooth devices are supported by mysensors. The one you've linked uses TI chip.

[electrik]

@monte Thanks. I didn't notice it was not a Nordic one. So if I take such module, I just have to figure out the pins to program and it can be re-used.
Did you or someone else ever tried this?

https://nl.aliexpress.com/item/4000389437486.html?spm=a2g0o.productlist.0.0.454562f4dPgTnm&algo_pvid=453cb8be-1c2a-43ea-a56c-61bbbf3a4822&algo_expid=453cb8be-1c2a-43ea-a56c-61bbbf3a4822-26&btsid=2100bdf116156431118194203efa5d&ws_ab_test=searchweb0_0,searchweb201602_,searchweb201603_

[nagelc]

Hi @electrik

You can program these ibeacons to work with MySensors.
I reprogrammed one by soldering some wires to a jlink adapter. Not elegant, but it worked.
Some type of push pin setup would be good if you are going to actually use these modules.

The version I got had only a button on the board, and no way to easily add any other sensors, so they weren't very useful. It would be interesting to try the ones with the temperature and acceleromator.

[abelson]

I am using a generic nRF52 dev board with the Arduino nRF52 core. I am trying to get a sample BLE service to display, but it cannot find it on my BLE scanner. After I couldn't get that to work, I decided to make the code even simpler. Since the dev board that I am using has a serial USB out I thought I would just check if I could get a "Hello World!" to the serial monitor... After flashing the soft device, I still couldn't get any output on my serial monitor.

Open On-Chip Debugger 0.10.0-dev-00254-g696fc0a (2016-04-10-10:13)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
debug_level: 0
0x4000
adapter speed: 10000 kHz
nrf52.cpu: target state: halted
target halted due to debug-request, current mode: Thread 
xPSR: 0x61000000 pc: 0x0001b08e msp: 0x20001188
nrf52.cpu: target state: halted
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc
** Programming Started **
auto erase enabled
nrf52.cpu: target state: halted
target halted due to breakpoint, current mode: Thread 
xPSR: 0x61000000 pc: 0x2000001e msp: 0xfffffffc
wrote 114688 bytes from file C:\Users\Admin\Documents\ArduinoData\packages\sandeepmistry\hardware\nRF5\0.7.0/cores/nRF5/SDK/components/softdevice/s132/hex/s132_nrf52_2.0.1_softdevice.hex in 2.559271s (43.762 KiB/s)
** Programming Finished **
** Verify Started **
nrf52.cpu: target state: halted
target halted due to breakpoint, current mode: Thread 
xPSR: 0x61000000 pc: 0x2000002e msp: 0xfffffffc
nrf52.cpu: target state: halted
target halted due to breakpoint, current mode: Thread 
xPSR: 0x61000000 pc: 0x2000002e msp: 0xfffffffc
verified 110636 bytes in 0.372659s (289.924 KiB/s)
** Verified OK **
** Resetting Target **
shutdown command invoked

I am using OpenOCD and an ST-Link v2 to upload my code and it looks like it is uploading successfully. Here is the output when I try to flash the S132 soft device:

void setup() {
  Serial.begin(9600);
  Serial.println("Starting...");

}

void loop() {
  Serial.println("Hello World!");
  delay(1000);

}

I also tried running this code with the MySensors library:

#define MY_RADIO_NRF5_ESB
#include <MySensors.h>

void setup() {
  Serial.begin(9600);
  Serial.println("Starting");
}

void loop() {
  Serial.println("Hello World!");
  delay(3000);
}

And got this error:

In file included from C:\Users\Admin\Documents\ArduinoData\packages\sandeepmistry\hardware\nRF5\0.7.0\cores\nRF5/Arduino.h:5:0,
                 from sketch\MyBoardNRF5.ino.cpp:1:
c:\users\admin\documents\arduinodata\packages\sandeepmistry\tools\gcc-arm-none-eabi\5_2-2015q4\lib\gcc\arm-none-eabi\5.2.1\include\stdint.h:9:26: fatal error: stdint.h: No such file or directory
compilation terminated.
exit status 1
Error compiling for board MyBoardNRF5 nRF52832.
Error while flashing SoftDevice.
java.io.FileNotFoundException: C:\Users\Admin\Documents\ArduinoData\packages\MySensors\hardware\nRF5\0.3.0\softdevices.txt (The system cannot find the file specified)

[monte]

@abelson first you have to flash SD and then chose softdevice in board options and flash your sketch.
It seems that you are lacking softdevice binary. It seems that your version of sandeepmistry's NRF5 core is pretty outdated, you have 0.3 version when surrent version is 0.7. No wonder that links to softdevice binaries are broken in softdevices.txt. Try updating core to the latest version and/or downloading softevice binary from nordic's site yourself.

[abelson]

@monte that makes sense. Do you know what options I have to do to flash the sketch after I flash the soft device? If I get the above output that I posted, does that mean that the soft device flashed successfully?

[monte]

@abelson no. You need to have softdevice binary on your PC to flash it to NRF board. Please, read my answer above and try to do, what I suggested.

You need to choose softdevice option if it has been flashed to the board.

[electrik]

This post is deleted!

[electrik]

@BearWithBeard
Great explanation, thanks!
On my windows 10 installation I had to run Zadig to make the programming from platformIO work.

[electrik]

@BearWithBeard
What did you do to get the serial pins of the Ebyte development board configured correctly, when using the generic board variant in platformIO? I've copied MyBoardNRF5.cpp but this is not used it seems.
Also redefining the definitions from variant.h

#define PIN_SERIAL_TX (11)
#define PIN_SERIAL_RX (12)

doesn't give serial output.

[BearWithBeard]

@electrik Yeah, I ran into that issue, too. Not sure if that's the proper way to solve it, but I add a custom board directory to the build flags in platformio.ini ...

build_flags = 
	-I $PROJECT_DIR/boards/generic

... and copied the board variant files from .platformio/packages/framework-arduinonordicnrf5/variants/Generic/ to boards/generic/ in my project folder. Changes made in here aren't ignored or overwritten by global PIO definitions.

[electrik]

@BearWithBeard Thanks that did it.
Could it be the TX and RX are switched on the BMP in your post?

[BearWithBeard]

@electrik Good to hear. And yes, I think you are right. I'll swap them and change the naming to RXI and TXO to clarify the directionality. Thanks for the hint!

[Ivanli]

Great post, thanks a lot for sharing.

[nagelc]

With respect to initial erase of NRF52, I have been using @BearWithBeard Black Magic Probe instructions successfully for years. But, my latest set of Minew boards doesn't respond.
I found that there is a new lock procedure from Nordic:

https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/working-with-the-nrf52-series-improved-approtect

I have tried upgrading my gdb and also J-Link EDU and nrfjprog tool chains and have not successfully connected to the new boards yet.

Has anyone had success with unlocking one of these new boards?

[NeverDie]

@nagelc Sorry I don't have an informed answer, but thanks for posting and making us aware of your experience with the minew's! Haven't heard from you in a while. Have you tried upgrading the firmware on the J-link that's part of a DK? I can't say that I have, but the firmware upgradeability was one of the alleged selling features of a DK's J-Link. That potential upgradeability didn't ever seem to matter, but maybe now it does.

As for me, after a long break I'm back to have a run at getting the nRF52805 to work. So far I've got bare metal blinking and bare metal UART working. I'm opting for bare metal code because it's unclear how well anything else will work with the nRF52805, which doesn't seem all that well supported. Soon to get some basic bare metal proprietary radio working, I hope.... If successful, I'll post it to github to memorialize it. There are surprisingly few examples of bare metal code out there, even though that's all the datasheet itself talks about. I guess I can understand why, because I've found some surprising ambiguities in the datasheet. For instance, who would have thought that PSELTXD would refer to an actual pin number and not to a bitmask? From the datasheet I thought for sure it would be a bitmask (like nearly everything else in the datasheet), but no, it's the actual pin number. I mean, why does the datasheet show literally every bit of a 32 bit word is relevant for specifying the pin number? On a different issue, bare metal UART doesn't work quite right without some artificial delays, even if driven by interrupt events, apparently because the actual generated baudrates aren't exactly right (something the datasheet admits). So, there's some finessing involved that you don't see when you're only working from abstracted libraries.

Regardless, the architecture itself remains pretty cool, and I enjoy it a lot!

[nagelc]

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 --recover

I 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]

@NeverDie Interesting chip for a sensor node. All the other NRF52s have way more capability than we are likely to use in a low power sensor node. The 52805 seems to have just enough. Hope you are able to make some progress.

[NeverDie]

@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 --recover

I 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.
  }

[NeverDie]

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 --eraseuicr

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

[NeverDie]

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:
Pro Mini nRF52: Less than 2µA System ON Sleep from 3v – 01:08
— Pro Mini Micros

Indeed, 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.

[monte]

@NeverDie have you checked the radio already? How much work is needed to make it work with mysensors?

[NeverDie]

@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 ). 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).

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]

@NeverDie are you saying it is only programmable with j-link? Won't stlink/blackmagic work?

[NeverDie]

@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?

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]

@NeverDie sorry, where did you buy them? I don't see them anywhere

[NeverDie]

@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]

@NeverDie yep, you're lucky:) Mouser says "Expected 09-Dec-22"

[NeverDie]

@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]

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

[NeverDie]

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.

[NeverDie]

One shortcoming of the nRF52805 that I just ran across: it has no LPCOMP. I'm surprised, as it's rather basic functionality.

[NeverDie]

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.

[ncollins]

@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

[NeverDie]

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!

[NeverDie]

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