nRF5 action!

[Omemanti]

@toyman yup, I tried that one, but all it kept saying was something like; can't find programmer.. and this method, which has a GUI, worked without incident

[Toyman]

@omemanti that's strange, I use the methos regularly and it worls fine.
Oh! Actually, sandeep's installation messes up Jlink drivers so they require reinstall for the method to work.
That's why I am using arduino nrf5 with BMP to completely separate Arduino from Jlink

[NeverDie]

FYI, I'm switching from uPython over to uLisp. It already worked on the BBC:microbit, and I just now got uLisp working on the nRF52832. Because uLisp relies on Sandeep's library, it doesn't yet support the nRF52840. However, if/when Sandeep's library does support the nRF52840, the uLisp upgrade will be fairly easy.

http://www.ulisp.com/

[Nca78]

@neverdie said in nRF5 action!:

FYI, I'm switching from uPython over to uLisp.

What is the reason for this switch ?

[NeverDie]

@nca78

1. uPython seemed to require an intimate understanding of a rather complicated build process. I kept running into build-related snags. Maybe in the future they will simplify it.
2. Its garbage collector can't handle heap fragmentation, and it appears that it never will.
3. Adding c-extensions is a rather arcane process.

In contrast, the uLisp build process is far simpler, and uLisp appears to have a proper garbage collector. Adding c-extensions is relatively easy.

[NeverDie]

For anyone interested, I posted a simple nRF52 Tx and Rx demo program written in Forth: https://github.com/rabbithat/nRF52_SimpleTxRxDemo

This code is a good starting point for beginners, because it is already working. You can easily modify the code to do whatever transmitting and receiving you want.

[NeverDie]

I just now posted a wireless Forth REPL for nRF52's on github:
https://github.com/rabbithat/nRF52_wireless_Forth_REPL

This allows you to wirelessly connect with a nRF52 remote node to update and/or interact with your code exactly the same as if the remote node was directly connected to your computer.

[smilvert]

I have recently installed an Ebyte E73 as my gateway with a DHT22. The problem is that I need to restart the gateway every 2 days and I can't figure out why. Can someone help me?

/**
   The MySensors Arduino library handles the wireless radio link and protocol
   between your home built sensors/actuators and HA controller of choice.
   The sensors forms a self healing radio network with optional repeaters. Each
   repeater and gateway builds a routing tables in EEPROM which keeps track of the
   network topology allowing messages to be routed to nodes.

   Created by Henrik Ekblad <henrik.ekblad@mysensors.org>
   Copyright (C) 2013-2017 Sensnology AB
   Full contributor list: https://github.com/mysensors/Arduino/graphs/contributors

   Documentation: http://www.mysensors.org
   Support Forum: http://forum.mysensors.org

   This program is free software; you can redistribute it and/or
   modify it under the terms of the GNU General Public License
   version 2 as published by the Free Software Foundation.

 *******************************

   REVISION HISTORY


*/

// Enable debug prints
#define MY_DEBUG

// Enable serial gateway
#define MY_GATEWAY_SERIAL



// Set blinking period
#define MY_DEFAULT_LED_BLINK_PERIOD 300

// Enable and select radio type attached
//#define MY_RADIO_NRF24
#define MY_RADIO_NRF5_ESB
//#define MY_RADIO_RFM69
//#define MY_RADIO_RFM95

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

int switch_led = 1;
#define ledPin 11
// Set this to the pin you connected the DHT's data pin to
#define DHT_DATA_PIN 02
#define DHTTYPE DHT22   // DHT 22  (AM2302), AM2321


// Set this offset if the sensor has a permanent small offset to the real temperatures.
// In Celsius degrees (as measured by the device)
#define SENSOR_TEMP_OFFSET 0

// Sleep time between sensor updates (in milliseconds)
// Must be >1000ms for DHT22 and >2000ms for DHT11
static const uint64_t UPDATE_INTERVAL = 600000;

// Force sending an update of the temperature after n sensor reads, so a controller showing the
// timestamp of the last update doesn't show something like 3 hours in the unlikely case, that
// the value didn't change since;
// i.e. the sensor would force sending an update every UPDATE_INTERVAL*FORCE_UPDATE_N_READS [ms]
static const uint8_t FORCE_UPDATE_N_READS = 10;

#define CHILD_ID_HUM 1
#define CHILD_ID_TEMP 0

float lastTemp;
float lastHum;
uint8_t nNoUpdatesTemp;
uint8_t nNoUpdatesHum;
bool metric = true;

MyMessage msgHum(CHILD_ID_HUM, V_HUM);
MyMessage msgTemp(CHILD_ID_TEMP, V_TEMP);
DHT dht(DHT_DATA_PIN, DHTTYPE);

void setup()
{
    hwPinMode(LED_BUILTIN,OUTPUT_D0H1);

    NRF_CLOCK->INTENSET=B11;  //enable interrupts for EVENTS_HFCLKSTARTED and  EVENTS_LFCLKSTARTED
    NRF_CLOCK->TASKS_HFCLKSTART=1;  //start the high frequency crystal oscillator clock
    while (!(NRF_CLOCK->EVENTS_HFCLKSTARTED)) {} //wait until high frequency crystal oscillator clock is up to speed and working

    pinMode(PIN_LED1, OUTPUT);
    digitalWrite(PIN_LED1, HIGH);

    dht.begin(); // set data pin of DHT sensor
}

void presentation()
{
    // Send the sketch version information to the gateway and controller
    sendSketchInfo("Serial Gateway nrf52", "1.0");
    wait(500);
    // Register all sensors to gw (they will be created as child devices)
    present(CHILD_ID_TEMP, S_TEMP);
    present(CHILD_ID_HUM, S_HUM);
}

void loop()
{

    // Reading temperature or humidity takes about 250 milliseconds!
    // Sensor readings may also be up to 2 seconds 'old' (its a very slow sensor)
    float h = dht.readHumidity();
    // Read temperature as Celsius (the default)
    float t = dht.readTemperature();
    // Read temperature as Fahrenheit (isFahrenheit = true)
    float f = dht.readTemperature(true);
    Serial.print("Test print");
    // Check if any reads failed and exit early (to try again).
    if (isnan(h) || isnan(t) || isnan(f)) {
    //Serial.println("Failed to read from DHT sensor!");
    return;
    } else {
    send(msgHum.set(h, 1));
    send(msgTemp.set(t, 1));

    }

    wait(UPDATE_INTERVAL);
}

[magkudjee]

Hi every one. I'm very new in mysensors (I use bad English)
in my sketch how to setup sleep,interrupt for 3 button (์NRF51822)
thank you

#define MY_DEBUG 
#define MY_NODE_ID 4

//#define MY_RADIO_NRF24
#define MY_RADIO_NRF5_ESB

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

#define CHILD_ID_SW1 1
#define CHILD_ID_SW2 2
#define CHILD_ID_SW3 3

#define BUTTON1_PIN 3
#define BUTTON2_PIN 4
#define BUTTON3_PIN 5

boolean sw1State;
boolean lastState1;
boolean tripped1 = HIGH;

boolean sw2State;
boolean lastState2;
boolean tripped2 = HIGH;

boolean sw3State;
boolean lastState3;
boolean tripped3 = HIGH;

MyMessage msg1(CHILD_ID_SW1, V_TRIPPED);
MyMessage msg2(CHILD_ID_SW2, V_TRIPPED);
MyMessage msg3(CHILD_ID_SW3, V_TRIPPED);

void presentation() 
{
  sendSketchInfo("Push Button 1", "1.0");
  
  present(CHILD_ID_SW1, S_DOOR); 
  present(CHILD_ID_SW2, S_DOOR);
  present(CHILD_ID_SW3, S_DOOR); 
}

void setup() 
{
  pinMode (BUTTON1_PIN,INPUT_PULLUP);
  pinMode (BUTTON2_PIN,INPUT_PULLUP);
  pinMode (BUTTON3_PIN,INPUT_PULLUP);

}
 
void loop() 
{ 
  sw1State = digitalRead(BUTTON1_PIN);
  if ( ( sw1State == LOW) && (lastState1 == HIGH) ) tripped1 = !tripped1;
  send(msg1.set(tripped1==HIGH ? "1" : "0"));
     lastState1 = sw1State;

  sw2State = digitalRead(BUTTON2_PIN);
  if ( ( sw2State == LOW) && (lastState2 == HIGH) ) tripped2 = !tripped2;
  send(msg2.set(tripped2==HIGH ? "1" : "0"));
     lastState2 = sw2State;

  sw3State = digitalRead(BUTTON3_PIN);
  if ( ( sw3State == LOW) && (lastState3 == HIGH) ) tripped3 = !tripped3;
  send(msg3.set(tripped3==HIGH ? "1" : "0"));
     lastState3 = sw3State;

  //sleep(digitalPinToInterrupt(BUTTON1_PIN), CHANGE, 0);    
  //sleep(INTERRUPT, CHANGE, 0);
}

[Omemanti]

@smilvert do you have some more information? like some serial output?

I had some issues with statements that uses millis(), in about 1,5 up to 2 days (much shorter the normaly I suppose) it did its rollover back to 0. This messed some waiting times for me.

[nagelc]

@magkudjee
MySensors will support 2 interrupts using sleep. I do not think it will support 3.
Use this format for the sleep call:
sleep(interrupt1, mode1, interrupt2, mode2, ms=0);
In your case: sleep(BUTTON1_PIN, CHANGE, BUTTON2_PIN, CHANGE, 0);

I don't know how to handle the 3rd interrupt.

Check the MySensors API document here: https://www.mysensors.org/download/sensor_api_20#sleeping

[smilvert]

@omemanti Well it seems to start working now... Hopefully it works Havn't restart the gateway in 2 weeks now

[mr_red]

@toyman @Omemanti

For Documentations sake:
I was having the same problems of the Ebyte E73 Module of being locked.
The ST_LinkV2 Clone Firmware are not able to recover the modules as the swd implementation is missing some direct register write capabilities.
The nfrjprog and nor openocd are working with the ST_LinkV2.

As suggested in this thread somewhere, I was able to get the modules unlocked with the Jlink clone and nrfjprog.
see also :
https://github.com/micooke/arduino-nRF5-smartwatches/blob/master/nrf52_disable_read_protection.txt

That (pirated) Firmware is working with swd and is able to recover the modules. Had to solve some dll-issues before, but got it working.
After the recovery with nrfjprog the stlink and the jlink are working as expected with openocd.

To find out if your wiring etc. is fine and it is really the locked devices you get this when starting your openocd interface.
The voltage is fine but the breakpoints are recognized.

Info : STLINK v2 JTAG v17 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.241270
Info : nrf52.cpu: hardware has 0 breakpoints, 2 watchpoints
Error: timed out while waiting for target halted
TARGET: nrf52.cpu - Not halted

It should be

Info : nrf52.cpu: hardware has 6 breakpoints, 4 watchpoints

[ileneken3]

@mr_red
I can add some of my own "documentation" on this issue. I only recently was able to program an Ebyte E73 module, and it was a long struggle. I used the NRF DK, and had help from a Nordic engineer.

• The recommended way to connect to the external device is:

Using the P20 and P1 headers, connect:
P20 VDD -> 3.3v on EBYTE 2G4M04S1B module
P20 SWDIO -> SWDIO on EBYTE 2G4M04S1B module
P20 SWDCLK -> SWDCLK on EBYTE 2G4M04S1B module
P20 VTG -> P1 VDD
P1 GND -> GND on EBYTE 2G4M04S1B module

To unlock the chip, execute:

nrfjprog -f nrf52 --recover

They also recommend using nrfjprog to program the device, because nRFgo Studio is deprecated. But I used the Studio and it worked fine. I gave Studio the .hex produced by the Arduino IDE using "Sketch" -> "Export compiled Binary".

As mentioned in the previous post, it is unlikely to unlock the board with anything but the NRF DK or a genuine J-Link. (Maybe a good fake J-Link).

Mistakes others may be able to learn from:

• Soldering the module onto a custom board can be hard. If you miss a little solder on SWDCLK or SWDIO, there is no hope. Check continuity on every pin you need!
• Make sure you don't order a NRF52810 module - only NRF52832 . You can program them, but Mysensors is not compatible. It's easy to hit the wrong link on AliExpress as they look identical.
• The NRF DK seems to deliver only 2.8V to the device. I first thought there was a problem, and tried to connect external power sources. But it seems to work powered from the DK.

[magkudjee]

@nagelc

thank you

[mr_red]

@ileneken3
It is a struggle indeed. I wanted to stay "low cost" with clone stlink and clone jlink.
As this is in preparation for a local hackspace workshop the entry level should be as low as possible.
And I suceeded to get this running for under 10€. (only one Jlink needed to unlock the modules once)

I am using platform.io and arduino, which use openocd internally. No need for nrfgo or an second programm and take the hex somewhere else.
Highly recommend platform.io for this! Flashing & Serial output are superfast, nice IDE and my dev-cycle speed up by an order of magnitude.

Question:
I am using an second device for USB-Serial convertion to get some print-msg out of the nrf52832.
Is there any way to do this over the programmer?

You can define the RX/TX pins in the nrf52832 to the pins you want.
Hardware Workaround by Neverdie: Connector Board -openhardware.io

[Toyman]

@mr_red said in nRF5 action!:

Is there any way to do this over the programmer?

Not in Arduino. In KEIL you can use RTT (pretty cool stuff, debug via SWD)
But if you just want to decrease a number of programmers, you can use Black Magic Probe, made from BluePill ($2 at Ali). It is 2-in-1 SWD and USB-UART converter on one PCB

[alowhum]

@ileneken3 @mr_red Thanks for this! Glad to hear I wasn't going crazy, but that others have had the same issue.

[Omemanti]

A quick Google pointed me to https://github.com/AndruPol/nrf52832-recover/blob/master/README.md

I do have a STM32F103C8T6 laying around. But ATM no time to play with it.

Maybe that's the €3 solution for unlocking.

[Toyman]

@omemanti said in [nRF5 action!]Maybe that's the €3 solution for unlocking.

BMP is enough to unlock. BluePill costs ca. €2 and it's easily convertable to BMP

[mr_red]

@Omemanti Good find about the BMP to recover the Ebyte module. Can you point me to an aliexpress link? "stm32" "bluepill" are not the magic chinese keywords..

[mfalkvidd]

@mr_red https://medium.com/@paramaggarwal/converting-an-stm32f103-board-to-a-black-magic-probe-c013cf2cc38c has keywords and a direct link to Ali

[alowhum]

I created a BMP, both from a cheap ST-Link and an STM32, and it didn't help me break open those eByte NRF52 units.

[mr_red]

@alowhum where did you get stuck? Whats your process?

[waspie]

@monte do you have final code now ?

[ileneken3]

@mr_red

I got to the point where the stm32loader.py runs and outputs:

Bootloader version 22
Chip id: 0x410 (STM32 Medium-density)
Write 256 bytes at 0x8000000
Write 256 bytes at 0x8000100
[..snip..]
Write 256 bytes at 0x8001900
Write 256 bytes at 0x8001A00
Read 256 bytes at 0x8000000
Read 256 bytes at 0x8000100
[..snip..]
Read 256 bytes at 0x8001900
Read 256 bytes at 0x8001A00
Verification OK

After that, you're supposed to plug in to the USB directly. I get " USB device not recognized". Zadig doesn't help. It lists it as:

"Unknown USB Device (Device Descriptor Request Failed)"

Any ideas?

Thanks.

[Toyman]

@ileneken3 have you returned the jumpers back?

[ileneken3]

@toyman
Unfortunately, yes, I have returned the jumpers to their original settings, and have even tried all 4 combinations.
I also changed computers, changed OS's, changed cables.

The board LOOKS like it was well manufactured, but I suppose a bad board is a possibility. Other than that, I can't figure out what could be wrong.

[sebi]

@d00616 said in nRF5 action!:

@Nca78 said in nRF5 Bluetooth action!:

Does that mean I have to go the long hard way with a bluepill as programmer and openocd ? Anyone has other ideas to unlock and erase the device ?

Select in to Tools menu "None" Softdevice and then "Burn Bootloader". This raises an error but the device is erased completely.

I am having the same issue trying to write on a E73 module with read/write protections. I don't have a JLink, but a ST Link-V2 and OpenOCD.
Do you know how to remove the protections on the E73 with such tools? Thanks.

[novicit]

@sebi,
A couple weeks ago I began exploring deploying E73 modules and had to remove protections. I was successful and now have a working E73 ethernet gateway. Only had ST Link-V2, so I used a "blue pill" I had in inventory to load it with Black Magic Probe. This cleared the protections.

The instructions I followed to load the BMP are step-by-step at https://github.com/TamojitSaha/STM32f103_Black-Magic-Probe

The instructions followed to clear protections with BMP also are step-by-step and worked perfect. They are at https://github.com/AndruPol/nrf52832-recover

In item #4, the program arm-none-eabi-gdb.exe seems to be part of the Arduino tool chain as I found it just by doing a search in file explorer and it was already on my win10 machine. Also, in item #4, (gdb) is the prompt that the program arm-none-eabi-gdb.exe gives. In the first line, change the '/dev/ttyACM0' to your com port. Use 'quit' to exit the program. Also, use 'mon help' to see options.

There are apparently a number of ways to 'recover' the E73, but this worked easily for me, and was step-by-step.

[ncollins]

@NeverDie Hoping you can help me with an WTNRF51822-S4AT problem where my stop recognizing interrupt events 2ish days after the last interrupt.

The buttons sleep for 24 hours, then wake up and send battery level. Even though the interrupt stops triggering, they still send battery level.

Possible some kind of timer is expiring?

Any help is appreciated.

// General settings
#define SKETCH_NAME "ThinButton"
#define SENSOR_NAME SKETCH_NAME
#define SKETCH_VERSION "1.4"

#define MY_NODE_ID 37


#define MY_BAUD_RATE 115200
//#define MY_DEBUG

#define IS_NRF51 
#define PIR_DETECTION_PIN 3
#define SHORT_WAIT 50
#define DEBOUNCE_MS 1000

volatile bool motion_change=false;

#define MY_RADIO_NRF5_ESB

#include <MySensors.h>

#define SLEEP_MS 1000 * 60 * 60 * 24

#define   CHILD_ID_VOLT 1
MyMessage msgBattery(CHILD_ID_VOLT, V_VOLTAGE);

#define CHILD_ID_BTN 2
#define BTN_PIN PIR_DETECTION_PIN
MyMessage msgBtn(CHILD_ID_BTN, V_TRIPPED);

void disableNfc() {  //only applied to nRF52

  #ifndef IS_NRF51
    //Make pins 9 and 10 usable as GPIO pins.
    NRF_NFCT->TASKS_DISABLE=1;  //disable NFC
    NRF_NVMC->CONFIG=1;  // Write enable the UICR
    NRF_UICR->NFCPINS=0; //Make pins 9 and 10 usable as GPIO pins.
    NRF_NVMC->CONFIG=0;  // Put the UICR back into read-only mode.
  #endif
}

void turnOffRadio() {
  NRF_RADIO->TASKS_DISABLE=1;
  while (!(NRF_RADIO->EVENTS_DISABLED)) {}  //until radio is confirmed disabled
}

void turnOffUarte0() {
  #ifndef IS_NRF51  
    NRF_UARTE0->TASKS_STOPRX = 1;
    NRF_UARTE0->TASKS_STOPTX = 1;
    NRF_UARTE0->TASKS_SUSPEND = 1;
    NRF_UARTE0->ENABLE=0;  //disable UART0
    while (NRF_UARTE0->ENABLE!=0) {};  //wait until UART0 is confirmed disabled.
  #endif

  #ifdef IS_NRF51
    NRF_UART0->TASKS_STOPRX = 1;
    NRF_UART0->TASKS_STOPTX = 1;
    NRF_UART0->TASKS_SUSPEND = 1;
    NRF_UART0->ENABLE=0;  //disable UART0
    while (NRF_UART0->ENABLE!=0) {};  //wait until UART0 is confirmed disabled.
  #endif
}

void turnOffAdc() {
  #ifndef IS_NRF51
    if (NRF_SAADC->ENABLE) { //if enabled, then disable the SAADC
      NRF_SAADC->TASKS_STOP=1;
      while (NRF_SAADC->EVENTS_STOPPED) {} //wait until stopping of SAADC is confirmed
      NRF_SAADC->ENABLE=0;  //disable the SAADC
      while (NRF_SAADC->ENABLE) {} //wait until the disable is confirmed
    }
  #endif
}


void turnOffHighFrequencyClock() {
    NRF_CLOCK->TASKS_HFCLKSTOP = 1;
    while ((NRF_CLOCK->HFCLKSTAT) & 0x0100) {}  //wait as long as HF clock is still running.
}


void mySleepPrepare() {  //turn-off energy drains prior to sleep
  turnOffHighFrequencyClock();
  turnOffRadio();
  turnOffUarte0();
}
 

void activateLpComp() {
  NRF_LPCOMP->PSEL=4; // monitor AIN0 (i.e. pin P0.02 on nRF52832 PIR Motion Sensor v607).
  while (!(NRF_LPCOMP->PSEL==4)) {} //wait until confirmed
  NRF_LPCOMP->REFSEL=3;  // choose 1/2 VDD as the reference voltage
  while (!(NRF_LPCOMP->REFSEL==3)) {} //wait until confirmed
  NRF_LPCOMP->ANADETECT=0;  //detect CROSS events on PIR detection pin
  while (NRF_LPCOMP->ANADETECT!=0) {} //wait until confirmed
  NRF_LPCOMP->INTENSET=B1000;  //Enable interrupt for CROSS event
  while (!(((NRF_LPCOMP->INTENSET)&B1000)==B1000)) {} //wait until confirmed
  NRF_LPCOMP->ENABLE=1;  //Enable LPCOMP
  while (!(NRF_LPCOMP->ENABLE==1)) {} //wait until confirmed
  NRF_LPCOMP->TASKS_START=1;  //start the LPCOMP
  while (!(NRF_LPCOMP->EVENTS_READY)) {}  //wait until ready
  
  NVIC_SetPriority(LPCOMP_IRQn, 15);
  NVIC_ClearPendingIRQ(LPCOMP_IRQn);
  NVIC_EnableIRQ(LPCOMP_IRQn);
}

void suspendLpComp() { //suspend getting more interrupts from LPCOMP before the first interrupt can be handled
  if ((NRF_LPCOMP->ENABLE) && (NRF_LPCOMP->EVENTS_READY)) {  //if LPCOMP is enabled
    NRF_LPCOMP->INTENCLR=B0100;  //disable interrupt from LPCOMP
    while (((NRF_LPCOMP->INTENCLR)&B0100)==B0100) {} //wait until confirmed
  }
}

void resumeLpComp() { //suspend getting interrupts from LPCOMP
  NRF_LPCOMP->INTENSET=B0100;  //Enable interrupt for UP event
  while (((NRF_LPCOMP->INTENSET)&B1000)!=B0100) {} //wait until confirmed
}
// setup
void setup() {
  hwInit();
  hwPinMode(PIR_DETECTION_PIN,INPUT);

  disableNfc();  //remove unnecessary energy drains
  turnOffAdc();  //remove unnecessary energy drains
  activateLpComp();
  motion_change=false;
}

void mySleep(uint32_t ms) {
   mySleepPrepare();  //Take steps to reduce drains on battery current prior to sleeping
   sleep(ms);
}


// presentation
void presentation() {
  sendSketchInfo(SKETCH_NAME, SKETCH_VERSION);

  present(CHILD_ID_VOLT, S_MULTIMETER, SENSOR_NAME);
  wait(SHORT_WAIT);
  present(CHILD_ID_BTN, S_MOTION, SENSOR_NAME);
  wait(SHORT_WAIT);
}

unsigned long lastTripped = millis();

// loop
void loop() {
  mySleep(SLEEP_MS);
  
  if(motion_change){
    unsigned long ms = millis();
    long timeDiff = ms - lastTripped; 
    
    if(timeDiff < 0 || timeDiff > 1000){ 
      send(msgBtn.set((uint8_t) 1));
    }
     
    NRF_LPCOMP->EVENTS_CROSS=0;
    motion_change=false;
    lastTripped = millis();
  } else {
    
    send(msgBattery.set(getInternalVoltage(),3));
  }
}

float getInternalVoltage(){
  return ((float)hwCPUVoltage())/1000.0;
}


#if __CORTEX_M == 0x04
#define NRF5_RESET_EVENT(event)                                                 \
        event = 0;                                                                   \
        (void)event
#else
#define NRF5_RESET_EVENT(event) event = 0
#endif


// This must be in one line
extern "C" { void LPCOMP_IRQHandler(void) {motion_change=true; NRF5_RESET_EVENT(NRF_LPCOMP->EVENTS_CROSS); NRF_LPCOMP->EVENTS_CROSS=0; MY_HW_RTC->CC[0]=(MY_HW_RTC->COUNTER+2);}}

[NeverDie]

@ncollins

It has been a while. I may be switching to PIC: https://forum.mysensors.org/topic/10666/anyone-ever-look-into-ezbl-aka-easy-booloader-on-a-pic

The impression I get is that you just write the new hex file into flash, flip a switch in software, and bang, you switchover to the new firmware without skipping a beat. No need to even reboot.

I think anything with the best general solution for OTA updates is a better path than doing OTA firmware bootloader one-offs for each MCU. From what I've gathered, it seems PIC may be the only one with the generalized bootloader support that I'm looking for. I haven't tried PIC before, but I'll be receiving a PIC board on Tuesday to test out this new theory. I'm gravitating toward LoRa anyway, so for that I can't leverage anything from NRF5x anyway. LoRa is the closest thing to bulletproof wireless communications that I've found so far. It just works, with fantastic range and coverage while still fitting within FCC requirements.

PICs tend to consume less energy than both atmega's and nRF5x's while sleeping, so there may be some positive trade-offs to be had there as well.

I'll miss the tight integration possible with an nRF5x. Maybe someday there will be PICs with integrated LoRa radios? MicroChip makes both separately, so it could conceivably happen. They've already done it with SAM: https://pic-microcontroller.com/microchip-new-ultra-low-power-lora-sip/

[ncollins]

@neverdie Interesting, thanks for the info

[waspie]

@ncollins I had the same problem and sort of "solved" it by having it reboot every 3 hours (or maybe it was 6).

I don't know how to use the nrf5x stuff anywhere near well enough to actually fix it but it seems to work.

[ncollins]

@waspie I was actually about to go down that route. Would you mind posting a code snippet for how you're triggering the reboot?

[waspie]

@ncollins

throw this somewhere in your code:

void reboot() {
  wdt_disable();
  wdt_enable(WDTO_15MS);
  while (1) {}
}

and then calling the reboot (in the entire loop):

void loop() {

  if (motion_change) {
    motionDetected=!motionDetected;
    if (motionDetected) {
      send(msg.set("1"));  // motion detected
    }
    else {
      digitalWrite(LED_BUILTIN,LOW);  //turn-off LED to signify motion no longer detected
      send(msg.set("0"));  // send all-clear to prepare for future detections
    }    
    
    NRF_LPCOMP->EVENTS_CROSS=0;
    motion_change=false;
  }
  else { //must be a scheduled wake-up.  Time to report voltage as a heartbeat.
    batteryVoltage=((float)hwCPUVoltage())/1000.0;  //take voltage measurement after transmission to hopefully measure lowest voltage that occurs. 
    send(msg_S_MULTIMETER_V_VOLTAGE.set(batteryVoltage,3));  //send battery voltage with 3 decimal places
    time = millis();
    if (time > 14400000 ) {
      reboot();
    }
  }
  mySleep(1200000);  //sleep for 20 minutes
}```

[ncollins]

@waspie appreciate it, thank you

[Sergio Rius]

@NeverDie Interesting. What have pulled you from nrf52 towards PICs?
Can you post a link on the board you ordered, (or one like that)? Thanks.

[NeverDie]

@sergio-rius I'm still deciding. What's holding me back from plunging into pic is that. it appears, the pics won't be able to leverage the arduino libraries. For that reason, I think I'm probably better off staying arduino compatible. In the end, it may be less effort to simply write my own OTA firmware update bootloader.

[siamola]

@neverdie said in nRF5 action!:

@Terrence said in Minimalist SAMD21 TQFP32 Pro Mini:

@NeverDie I love the Feather boards. Currently working with the RFM69 feather. Build in battery connector/charger is very nice to have.

Have you found a cheaper source than Amazon for buying them?

where it's just every pin of the SAMD21 mapped to a post, and it's only just the SAMD21 chip on the board. Then I can experiment on breadboard and figure out what I want and what works before finally reducing it to a subsequent PCB.

[Sergio Rius]

Any charitative soul can help me prepare a black magic probe? I'm following the guides but at some point I can't continue.
For example, following this one: https://hackaday.io/project/28180-bluetooth-gamepad-phone-case/log/71316-stm32-black-magic-probe-flashing
I do:

$ mkdir mbp && cd mbp
$ wget https://raw.githubusercontent.com/jsnyder/stm32loader/master/stm32loader.py
$ chmod 774 stm32loader.py
$ sudo apt install python-pip
$ pip install pyserial # There I remove '--assume-yes' as this is a wrong parameter

# Then here starts the funk
$ sudo apt install arm-none-eabi-gdb  # The package does not exist.
# I found online that it may be already incorporated and my worth a try, so I continue.
# So I change the boot0 jumper to 1, that it not said in the guide, connect the two boards and plug it into the computer.

$ dmesg | grep tty
# Nothing.

$ sudo dmesg | tail
[10680.891711] usb 1-12: Product: STM32 STLink
[10680.891714] usb 1-12: Manufacturer: STMicroelectronics
[10680.891716] usb 1-12: SerialNumber: PÿqRpQP2$g
[11990.202434] usb 1-12: USB disconnect, device number 7
[11998.926846] usb 1-12: new full-speed USB device number 8 using xhci_hcd
[11999.076060] usb 1-12: New USB device found, idVendor=0483, idProduct=3748, bcdDevice= 1.00
[11999.076066] usb 1-12: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[11999.076069] usb 1-12: Product: STM32 STLink
[11999.076072] usb 1-12: Manufacturer: STMicroelectronics
[11999.076074] usb 1-12: SerialNumber: PÿqRpQP2$g
# But no usb port. So I add udev rule.

$ ls -l /dev/stl*
lrwxrwxrwx 1 root root 15 oct 15 14:32 /dev/stlinkv2_12 -> bus/usb/001/008

$ sudo ./stm32loader.py -p /dev/stlinkv2_12
Traceback (most recent call last):
  File "./stm32loader.py", line 427, in <module>
    cmd.open(conf['port'], conf['baud'])
  File "./stm32loader.py", line 71, in open
    timeout=5               # set a timeout value, None for waiting forever
  File "/home/sergio/.local/lib/python2.7/site-packages/serial/serialutil.py", line 240, in __init__
    self.open()
  File "/home/sergio/.local/lib/python2.7/site-packages/serial/serialposix.py", line 272, in open
    self._reconfigure_port(force_update=True)
  File "/home/sergio/.local/lib/python2.7/site-packages/serial/serialposix.py", line 326, in _reconfigure_port
    raise SerialException("Could not configure port: {}".format(msg))
serial.serialutil.SerialException: Could not configure port: (25, 'Inappropriate ioctl for device')

$ sudo apt install gdb-multiarch
# Same effect.

And here I am. Does anyone knows what kind of magic is required to put inside this little thing?

[scalz]

@Sergio-Rius
I can't help you with blackmagic probe unfortunately.
Just personal opinion, I prefer Segger probe.
For example, Segger EDU mini is cheap. for the price don't bother with clones..

• very affordable
• compatible with a lot of IDEs, and when you use it with Segger IDE then you get best integration
• segger provides lot of tools for debugging for free
• easy updates and drivers install

The only cons to a jlink probe could be no additional uart, but I don't need uart for debug&prints (segger ozone and rtt tools), and nor uploading sketch.

Or a nrf5dk board is a nice alternative too, a little bit more expensive than EDU Mini but you get jlink+devboard+ later you could hook a power profiler kit on it
Still a jlink mini at hand is quite useful.

Like I said just personal, I'm sure BMP is nice too, I guess you'll get it working before you can get a jlink

[monte]

@sergio-rius I too have struggled to flash st-link clone with bmp firmware, but eventually I managed to do it. Unfortunately I don't remember what exactly I did, but I remember that I came to a solution when decided to try another st-link as a destination. If I remember correctly, there are different stm32 chips on these boards and some of them have insufficient amount of flash memory for bmp firmware.

arm-none-eabi-gdb package is not available in ubuntu's repositories starting from 18.04. You can either download toolchain from eclipse's github archive or try to install older package as described here.

Also, I used info from this blogs when flashed my st-link:
http://blog.linuxbits.io/2016/02/15/cheap-chinese-st-link-v-2-programmer-converted-to-black-magic-probe-debugger/
http://nuft.github.io/arm/2015/08/24/blackmagic-stlink.html

As for buying stuff, don't forget you can buy ready to use BMP from their creators too

[NeverDie]

Maybe this will help: I once looked into the Black Magic Probe, but came to the conclusion that it was basically a PC program that they crammed onto the "probe." Therefore, unless I'm mistaken, you could run the very same source software from either a PC or a linux box and get the same results. I don't recall any advantage to running it on the so-called "probe" that the authors picked.

[monte]

@neverdie and how do you suggest connecting SWD and SWCLK lines from MCU to computer, not using the "probe"?

[Sergio Rius]

@monte I guess he means taking the debugger program to the computer layer and leave only the com channel to a TTL device.

[monte]

@sergio-rius but debugger is running on a computer side anyway, as far as I understand. And BMP is the "thing" that connects it to MCU via SWD.

[Sergio Rius]

@monte I may be wrong, but from what I understand while reading on it, it seems that the debugger is implemented in the probe. The program you run is an interface.
I see it like a Ilogger interface that you implement in a program.

[monte]

@sergio-rius well, I guess you are right. I revisited description of BMP and it says, that it runs GBD server on itself and eliminates need for STlink server. So I guess you could do all the same with just an st-link...however it seems that it would require more setup and I don't think that it will be easier than flashing BMP firmware
Just a snippet from their wiki:
"There are a few advantages of the Black Magic Probe. BMP is open-source, meaning that you can look inside it if you need or want to. We are getting support for new ARM Cortex-M based chips on a regular basis, so you are not limited to just the STM32. We have preliminary support for Cortex-A this will result in the ability to use the probe with Raspberry PI and Beagle Bone Black and many others. The Black Magic Probe also supports JTAG not only SWD, because not all microcontrollers use SWD. Also JTAG makes it possible to chain together more than one microcontroller. The GDB server is implemented on the probe itself, this means we do not use some proprietary protocol to talk to your debugger software, making the setup more repeatable and removing the need for custom config files."

[scalz]

"BMP is open-source, meaning that you can look inside it if you need or want to"

"The GDB server is implemented on the probe itself, this means we do not use some proprietary protocol to talk to your debugger software"

sounds so useful when you simply want to upload fw and debug
open-source does not mean better quality than proprietary imho, it can be a burden too. I prefer mature product for working.

is BMP compatible/integrated with as many IDE as a proprietary probe?
If for instance someday you want to use it with Segger IDE+nordic sdk, is it compatible? I don't think so.
I "compared" probes recently and decided to stick to jlink. The second probe in my list is cmsis-dap/daplink, looks nice too, but don't need it (at least, not so far)

I use many different toolchains and CLI too. So when there is a tool that just needs download and exec to install driver, autoupdates etc, without spending life in CLI, I don't hesitate.

struggling or working..

[monte]

@scalz well, that's nice that you know what you want and can get it, but that doesn't mean that's suitable for everybody else. That's good to have a choice, but when you need it done, you better find a way to get it done easier and faster.
So I went to local store, bought second st-link clone for 4$ and then spent a few hours figuring out, how to properly flash it. The day after I could unlock my Ebyte e73 board, with newly acquired BMP.
If I'd took the route suggested by you, I would spend minimum 30$ and 1-2 weeks of waiting time. And then I would still need to figure out how to work with that proprietary software.
I am far from experienced programmer, so I can't get use of BMP's full potential, but now I have a very useful tool in my arsenal, that can be used with variety of different chips.
Also, in my opinion, the main advantage of opensource not the software itself, but a community. Your experience may vary, but I'd say you have better chances finding solution in opensource community, than on commercial software forum, unless you have some kind of paid support subscription.

[NeverDie]

@monte said in nRF5 action!:

@neverdie and how do you suggest connecting SWD and SWCLK lines from MCU to computer, not using the "probe"?

st-link. Roger Clark previously had a youtube video showing this setup, but it looks as though he has since deleted all his videos: https://www.youtube.com/user/synergie8/featured

Anyhow, I'm not trying to dissuade anyone from using BMP. If you want a probe that has a command line interface built into it, then AFAIK it's still available.

[scalz]

@monte said in nRF5 action!:

@scalz well, that's nice that you know what you want and can get it, but that doesn't mean that's suitable for everybody else. That's good to have a choice, but when you need it done, you better find a way to get it done easier and faster.

Why so much impatience So many things to tinker.. I mean you can get a jlink in 2days if you need it. I ordered mine while I was waiting for stuff coming from China..and in my case, there is no close-door store for geeks.
Do you mean you would suggest a nrf5 newcomer to diy a BMP for mcu flashing??

When I got my jlink, I didn't have to flash it to make it working.. I just had to donwload win drivers, install them, and voilà.
Which proprietary sw do you think you need to learn?? I don't use any special sw for flashing..just regular IDEs like arduino/vs studio, or more advanced like Segger (free) or Keil. For all these IDEs, I just click on a button to upload fw, simple. There is nordic windows apps, or nrfjlink in CLI too.

I know the power of oss and its flaws, same for commercial, in practice it's not rare to see communities sitting/waiting for updates (not hard to find examples on github), whereas money makes commercial products live.
No need to debate on this, it's useless debate I think
The reality is different here, I think you'll find more subscriptions-free resources on internet about Jlink than BMP, and for a reason I agree that you'll find lot of howtos save a few bucks by diy-ing and flashing a BMP..
everyone acts in one's own interest
Just to sum up my thought, I think for a newcomer it's easier to get started with a Jlink vs diy probe that you need to flash with what, a probe ??

Below is a screenshot of a running nrf5 test, stability test.. but for example you can see, I don't use any additional uart for debug printing, and fw is just uploaded by a click in IDE.

[pichaty]

This post is deleted!

[monte]

@scalz I'm not trying to dismiss your point, I get it. It just surprises me that you stand against "diy'ing a probe" while still being a part of DIY community which gathered around idea of making things fast and cheap. Why bother with mysensors, if we can buy all the same from Ikea, Xiaomi of Philips, or many other manufacturers, sometimes not even much pricier?
To sum up what I'm trying to say, and finish this debate. I've spoken about my experience as nrf5 newcomer. And exactly as a newcomer I've found this way being better for me. I don't use Segger, Keil or Windows, nor I am planning to use them in future, and if I will, I would probably be able to afford buying myself a J-link.
To get "DIY" version of BMP you need either ST-link v2 or any STM32 board, bluepill for example. And to flash one of those you obviously need another ST-link. That's all.
BMP supports SWO which have it's own specifics compared to RTT, but basically does the same thing.

[NeverDie]

@monte There's also this alternative:

https://www.ebay.com/itm/Jeff-Probe-from-Flirc-Open-Source-JTAG/223682528208?hash=item34148483d0:g:VQMAAOSwhixdjR4-

if you're so inclined.

[monte]

@neverdie that seems to be for folks who are against STM32 chips

[scalz]

@monte
it's not standing against diy'ing etc..really you didn't understand my point, it's just about user friendly and easily repetable getting started for MySensors nrf5 newcomers, for simply flashing their sketch.. even if a diy BMP is certainly a good probe too. and a genuine BMP is more expensive than a jlink mini. Compare both a jlink vs a blank diy probe, and with a stopwatch, you'll see which method is faster and easier for a noob..

But ok, I won't insist anymore, if you prefer to get me wrong, really don't mind.. I should better let user with not much xp manage all alone so no debate, as this just makes me less active, see you next year

Just don't forget future newcomers will read your advices. In the meantime, we'll try to update docs for MySensors nrf5.

Have fun with your probe

[Sergio Rius]

@scalz C'mon, would you leave the forum with just one hit?
In fact I understand your point completely. Open source has become more and more caotic. Internet is atemporal, and often people has the bad habit of not putting the complete date at the top of their "articles" that makes that search engines cannot filter and order properly.
Everyone has a blog and writes whatever gets out him. The majority of people uses that as a remainder for themselves and... whynot getting reward. So there are zillions of howtos made anyhow. They are not written for helping people.

If the sources and destination are always one, why there aren't the binaries available and all writeups talk about messing the computer and compiling? I think that's because nowadays people seek praise for having achieved it.

Scalz point is about economy of time. Because time is money, even if it's spare time, and yes, a paid/proprietary probe becomes cheap, giving the documentation on the internet, today.

Also the point of view depends in the situation of everyone and its age. Someone at the 5thies feels earlier that it's wasting time, and there comes frustration, and complaining posts, unfortunately
Just buy a probe, forget about it until it gets delivered.

@monte BTW, I was trying to program an stm32 board with a jlink. Not a Jlink. Maybe if there was a way to get an already compiled binary (to avoid all those dependencies errors) and program the jlink with a normal serial ttl...

[monte]

@sergio-rius well, I've gotten majority of my computer knowledge and almost everything I know about programming MCU from such blog posts and articles. Some of them where better, some worse, maybe 10% were complete garbage. But anyhow I can't and won't complain. Because no person is obliged to write something that everyone will understand, and not everyone is naturally born teacher, to prepare information in suitable for wide variety of people way. But all of them were people, who thought it will be helpful to share their experience with others, to show them that this can be done, and maybe give at least hints to how to achieve it. I think there is not much use if you just follow steps, written by someone, without any thought process, or trying understand what you are doing. And thus when you try to achieve something that, won't work from the beginning and guide seems to be outdated, or not complete, you teach yourself and this is most precious in thewhole process.
I don't think it is correct to blame those, who made a guide for that you can't replicate all the steps. Time goes, libraries an packages evolve, and in few moths fully functional guide can become obsolete if you can't make some adaptations.
Anyway, here is more recent guide, but written with older ubuntu version in mind. You may look at it, if you want: https://buger.dread.cz/category/stm32.html

[Sergio Rius]

You know... Great power comes with a great responsibility

[NeverDie]

I happened just now to notice that ON Semiconductor has released their own (non-Nordic) version of an integrated Bluetooth + ARM Cortex + antenna with all passives:
https://www.mouser.com/datasheet/2/308/RSL10SIP-D-1511181.pdf

What's remarkable is that the entire thing, including the antenna and all the passives (which are built into it) is just 8mm x 6mm in size. As a result, it's very easy for them to make a very small sensor beacon:

"The RSL10 SIP features an on−board antenna, RSL10 radio SoC,
and all necessary passive components in one package to help minimize
overall system size. Already fully qualified to FCC, CE, and other
regulatory standards; RSL10 SIP removes the need for additional
antenna design considerations or RF certifications."

Personally, I don't currently have the skill to solder anything that small, but maybe with the PCBA services that are becoming available.....

I post this here merely as an illustration of what's truly possible. I can only guess, but I presume Nordic will probably (?) release something similar in the future. It would be nice not having to rely on module vendors but instead just mount the chip directly.

[NeverDie]

By the way, maybe the Black Magic Probe can function as a kind of "universal" JTAG interface? For instance, would it work well o an ESP32 and/or anything else that relies on JTAG for debugging and/or burning firmware? Or would an ST JTAG probe work just as well?

Is this right? I'd prefer to consolidate on a single thing rather than having a different JTAG interface device for every different kind of hardware that might need programming/debugging:

#274 Free Inline Debugging for ESP32 and Arduino Sketches – 17:46
— Andreas Spiess

[scalz]

@neverdie
afaik BMP officially targets ARM mcus, whereas ESP32 is not ARM, it's Tensilica.

[NeverDie]

@neverdie On the other hand, I bet that tiny RSL10 integrated radio+antenna package has very limited range. What I noticed from the various nRF52840 modules that I've tried is that the smaller the module, the worse the radio range. I haven't yet encountered any exceptions to that generalization.

[ncollins]

@waspie just to follow up, 24hr reboot() is working perfectly. Appreciate the help.

[waspie]

@ncollins good news

I wonder if this has anything to do with it?
https://forum.mysensors.org/topic/10705/nrf52-watchdog-problem-myboardnrf5

[ncollins]

@waspie Given that all of my interrupt nodes stopped triggering after 36 hrs (before your reboot workaround), it has to be related. It’s just weird that my nodes would continue to wake up and broadcast battery level.

Is the LPCOMP interrupt method dependent on the wdt? Maybe resetting/restarting the wdt every 24hrs would suffice? Or maybe you have to reactivate LPCOMP every 36 hr wdt cycle?

[NeverDie]

When are we going to see newer nRF52 modules featuring antenna diversity?

Somewhere I still have this prototype module that I purchased a few years ago:

I got it working and wrote about it at the time, but I haven't seen any more up-to-date modules featuring antenna diversity since then. Definitely nothing featuring an nRF52840, for instance. What gives?

[Calvin Khung]

Hello guys. I wished I have found this forum earlier. I'm currently trying to extract/dump a firmware from nRF51. Using OpenOCD and ST-Link V2. I am facing some problems and have posted it on stackexchange and stackoverflow. Here are the posts:

https://reverseengineering.stackexchange.com/questions/22897/blank-binwalk-and-binvis-io

https://stackoverflow.com/questions/59710114/dumping-nrf51s-firmware

Hopefully someone here could help me. Thanks in advance

[NeverDie]

@Calvin-Khung a black magic probe would allow you to do that.

[Calvin Khung]

@NeverDie What is the difference with a ST-Link? I mean, I've read the features on GitHub but I don't really get the differences though Sorry, as stated in both links, I'm still a noob.

[Calvin Khung]

Oh, is the command mass erase the same as dump image? If I mass erase, will the bin file appear in the bin folder?

[mr_red]

@Calvin-Khung Hi Calvin, I read your comments here and on Stackoverflow/exchange. I honestly think that you dont have the right skills to do this. The exploited vulnerability in the blog is quite sofisticated. I think you have to start getting your debugger configured correctly. Your say you have an st-link v2 which lets me to belive you have a cheap chinese clone.
This clone has not all debugging features included, as you might saw in my posts earlier. You are much better of with a Black magic probe or a J-Link.
Have you got a halted NRF51 yet?

[Calvin Khung]

@mr_red If it's a clone then that would probably explain why it wasn't successful. I've read a thing or two about the BMP. Do you think its a good idea to convert the cheap ST-Link V2 to a BMP? Found a blog about it.

http://blog.linuxbits.io/2016/02/15/cheap-chinese-st-link-v-2-programmer-converted-to-black-magic-probe-debugger/

J-Link is way too expensive so I won't even bother considering it. And I don't quite get what you mean but yeah, I did halt it during the process.

[monte]

@Calvin-Khung you can convert st-link clone into BMP. The only problem would be if there is not enough flash on the chip. If I remember correctly, BMP firmware needs more than 64kb. But you will know for sure, if you'll try.

[Calvin Khung]

@monte For sure, I'll give it a try. Thanks for helping out guys!

[Jokgi]

Calvin, You cam buy a Nordic Development kit for about $50 dollars or less. It has the J-Link OB device on it for swd programming and debugging.

[Nca78]

@Jokgi said in nRF5 action!:

Calvin, You cam buy a Nordic Development kit for about $50 dollars or less. It has the J-Link OB device on it for swd programming and debugging.

Best solution imho, never had a problem with it programming the nrf5 modules, just drag & drop from Windows file explorer.

[Jokgi]

@Calvin-Khung
Jokgi
Jokgi about 2 hours ago

Calvin, You can buy a Nordic Development kit for about $50 dollars or less. It has the J-Link OB device on it for SWD programming and debugging.

[NeverDie]

I agree with Jokgi, but nonetheless for anyone interested in the Black Magic Probe alternative, here's an article on how to make a BMP from a $2 Blue Pill board:
https://medium.com/@paramaggarwal/converting-an-stm32f103-board-to-a-black-magic-probe-c013cf2cc38c

[orhanyor]

i use $10 replica Jlink from aliexpress works ok with the latest firmware without an issue. i use it just to flash bootloaders to cortex m0-m4 and nrf52's but it should work for any task that a genuine jlink can do.

[Jon Raymond]

There also is an "Education" version of the Jlink for $20 if you want an official one with access to nRF Command Line Tools.

[Jokgi]

@Jon-Raymond Correct. It is a nice product for the price and the intended user. As Jon mentioned, you can use the command line tools as well as nRFconnect and also has direct hooks into the Segger Embedded Studio which is a fully functional IDE / compiler/ Debugger and is free when used with Nordic Semi devices.
Plus there is no license conflict as there is when using one of these cheap overseas j-link knock offs. (Which could "break / brick" anytime doing a "official" Segger update on these clones.)

[Calvin Khung]

@orhanyor good to hear! i ordered that as well since just to try it out in hope that it would work. now that you've said that, maybe i shouldn't worry too much then.

[orhanyor]

@Calvin-Khung Well im actually surprised that it still works because people are reporting they might stop working after a firmware update so you might wanna hold back on that other than that it works surprisingly well. i bought another as my back up plan which im expecting it in these days. its abit different than the one i have. this one is much cheaper and looks like jlink edu mini rather than a normal j link with a black box.. i ll see if it works when i receive it, here it is.
https://www.aliexpress.com/item/32669702891.html?spm=a2g0s.9042311.0.0.27424c4d4Fx7g9

[orhanyor]

i just received this little thing, tested it with atmel studio just to flash some M4 boards and it worked nicely. i wanted to update its firmware via jlink(playing with fire) but it didnt let me saying its up to date so its all ok i guess. it only has 4 pins 3v, gnd, swdio, swclk. for $2.50 in total with shipping its a steal

[Jon Raymond]

@orhanyor Is it just me or does that micro usb connector look like it should be mounted upside down so it actually nests into the cutout in the board below it? Of course the pinout would be mirrored but it seems like a layout issue that they just ran with.

[orhanyor]

usb connector is actually nested as far as i can see but it dips 1-2 mm only. weird but it works so its all good

[Calvin Khung]

This post is deleted!

[nagelc]

Does anyone have any experience with the minew modules?

https://www.aliexpress.com/item/4000111771020.html?spm=a2g0o.productlist.0.0.355350384gOEfO&algo_pvid=0304e5fd-2ee1-4b3c-8324-d7457ed54a60&algo_expid=0304e5fd-2ee1-4b3c-8324-d7457ed54a60-3&btsid=0ab50f4415945033578573060e726c&ws_ab_test=searchweb0_0,searchweb201602_,searchweb201603_

I've been using the Fanstel BT832 series with success, but I have been looking at this one to get a few more hand-solderable GPIOs.

[nagelc]

I received a few of the Minew MS50SFB modules. They appear to need unlocking similar to the E73 modules. I have tried using instructions as for E73, but no luck so far with either
gdb
https://forum.mysensors.org/topic/9266/guide-nrf5-nrf51-nrf52-for-beginners/54?_=1598203470928
acts like it is working, but doesn't really unlock the module.

or J-link
https://forum.mysensors.org/topic/9266/guide-nrf5-nrf51-nrf52-for-beginners/33?_=1598203470928
returns error from nrfjprob. In J-Link application can not connect

[NeverDie]

@nagelc If you do manage to get it working, I'd be curious as to what kind of range you get out of it a compared to other modules. The antenna pattern looks a bit different.

[NeverDie]

@nagelc It's a shot in the dark, but maybe you want to check the schematic for any differences with other modules that you've previously programmed successfully. Either it's a dud, or it must be that.

[Nca78]

@nagelc said in nRF5 action!:

I received a few of the Minew MS50SFB modules. They appear to need unlocking similar to the E73 modules. I have tried using instructions as for E73, but no luck so far with either
gdb
https://forum.mysensors.org/topic/9266/guide-nrf5-nrf51-nrf52-for-beginners/54?_=1598203470928
acts like it is working, but doesn't really unlock the module.

or J-link
https://forum.mysensors.org/topic/9266/guide-nrf5-nrf51-nrf52-for-beginners/33?_=1598203470928
returns error from nrfjprob. In J-Link application can not connect

Did you try with nRFgo Studio ? I use that with NRF52 DK and it's simple. But I've not tried those modules though.

[Jokgi]

@Nca78 nRFgo Studio has been put to sleep. nRFgo studio does not have support for the newer Nordic devices. nRFconnect for Desktop has taken its place. I suggest when using the nRF52-DK (or any nRF52 based DK) that this newer utility be used.

[Nca78]

@Jokgi said in nRF5 action!:

@Nca78 nRFgo Studio has been put to sleep. nRFgo studio does not have support for the newer Nordic devices. nRFconnect for Desktop has taken its place. I suggest when using the nRF52-DK (or any nRF52 based DK) that this newer utility be used.

Thank you I updated !

[Jokgi]

@Nca78 I suggest downloading the "command line tools" as well.
https://www.nordicsemi.com/Software-and-tools/Development-Tools/nRF-Command-Line-Tools.

[nagelc]

@NeverDie
It isn't very scientific, but I think the range is roughly equivalent to a BT832. I can reach my gateway from everywhere in my house except the far corner of the basement, same as the BT. That corner is behind a chimney an lots of plumbing -- RFM69 territory. Maybe the BT832F would work there. Haven't tried those.
After fixing a missing trace on my dev board (my fault, not Oshpark's), and updating my J-link and bmp software. I am able to program these.

I popped the shield off of one just to confirm I ordered the right version. The part numbering vs processor is not very clear on Aliexpress. No surprises there.

[NeverDie]

A Version 2 of the micro:bit is due to be released this month: https://www.electronicsweekly.com/news/products/bus-systems-sbcs/microbit-version-2-educational-computer-now-runs-ai-gets-loudspeaker-2020-10/

It's based around the 64Mhz, 128Kbyte RAM nRF52833: https://www.nordicsemi.com/Products/Low-power-short-range-wireless/nRF52833

Version 2 will include a speaker and a microphone and will apparently make use of bluetooth for wireless communication. The EW article also says it will support a "microbit-radio protocol". Also, the EW article says that Javascript will run on it.

By itself it's not that interesting, but for someone looking to get started, it's another way in.