nRF5 action!

NeverDie

Is no one else able to download the files either?

NeverDie

@NeverDie how many GND pins did you connect ?
It might be a stupid suggestion but maybe all GND pins are not connected together ?

Good question. I connected to just one GND pin. However, I just now checked with a DMM, and all the exposed GND pins on the module have continuity to one another. So, based on that, I'm assuming any additional outside connections would be redundant anyway?

mfalkvidd

@NeverDie said in nRF5 Bluetooth action!:

Is no one else able to download the files either?

From the forum, no. From hightail, yes.
I don't know which program to open them in though.

NeverDie

@mfalkvidd said in nRF5 Bluetooth action!:

I don't know which program to open them in though

The current theory (see above) is that maybe it's Altium Designer, which has a free viewer.

NeverDie

@NeverDie said in nRF5 Bluetooth action!:

One thing I notice on the Ebyte module is that no RESET pin is exposed. Isn't that a bit odd?

Correction: According to the Nordic datasheet, PO.21, which is exposed on the Ebyte modle, can also serve as the reset pin. I was thrown off because Sparkfun labeled it RESET on their board's silkscreen, not "PO.21".

NeverDie

@Nca78 said in nRF5 Bluetooth action!:

I have ordered a few of those modules too,

Do let us know if either of you are able to program it. After this Ebyte experience, I won't be taking it for granted anymore.

mfalkvidd

@NeverDie not sure if it applies to this case, but at 18:04 in https://youtu.be/JXQLI-nXqmQ it is mentioned that the chip's identifier needs to be included in some list when the softdevice is compiled (or something along those lines, I am not yet familiar with the vocabulary).

NeverDie

@mfalkvidd said in nRF5 Bluetooth action!:

@NeverDie not sure if it applies to this case, but at 18:04 in https://youtu.be/JXQLI-nXqmQ it is mentioned that the chip's identifier needs to be included in some list when the softdevice is compiled (or something along those lines, I am not yet familiar with the vocabulary).

My understanding (which may be wrong) is that in this context a "softdevice" is a veiled reference to the bluetooth stack and/or related bluetooth code, which at present the mysensors code isn't using. In any case, when I programmed both the adafruit and the sparkfun using the mysensors code, I didn't include a chip identifier in a list, nor any soft devices, and it worked anyway.

NeverDie

I was thinking that maybe the Ebyte module is stuck in some kind of reset mode, but I just now checked pin P0.21 (the reset pin), and it measures high at 3.3v. This is the same as for the Sparkfun board, which I have no trouble programming. Reset is active low.

d00616

@NeverDie said in nRF5 Bluetooth action!:

My understanding (which may be wrong) is that in this context a "softdevice" is a veiled reference to the bluetooth stack and/or related bluetooth code, which at present the mysensors code isn't using. In any case, when I programmed both the adafruit and the sparkfun using the mysensors code, I didn't include a chip identifier in a list, nor any soft devices, and it worked anyway.

I haven't tested MySensors with a present SoftDevice. The drivers/NVM code (EEPROM emulation) conflicts with the DFU bootloader.

It's better to see the SoftDevice as an Operating System providing BLE functionality and some hardware abstraction, while MySensors is directly ported to the hardware.

Toyman

@NeverDie stupid question: did you try to power it NOT from DK board and vise versa?

NeverDie

@Toyman said in nRF5 Bluetooth action!:

@NeverDie stupid question: did you try to power it NOT from DK board and vise versa?

Thanks for the suggestion! So far I've tried powering it from a USB 3.3v source (which is how I successfully programmed the adafruit and sparkfun boards), but I'll now try powering it from the DK and see if it makes a difference.

By the way, I found an alternate way to confirm that the board is using the built-in LDO rather than the DCDC converter. DEC4 is the output of the LDO, and it measures 1.3v (which is also the expected voltage output by the LDO if it were active). DCC is the output of the DCDC converter, and it measures 0.0v. So, empirical confirmation of what you all inferred earlier. :)

NeverDie

@Toyman said in nRF5 Bluetooth action!:

@NeverDie stupid question: did you try to power it NOT from DK board and vise versa?

Just now tried it, and unfortunately it didn't make a difference. :(

The actual text of the error message that I always receive is:

c:/users/david/appdata/local/arduino15/packages/sandeepmistry/tools/gcc-arm-none-eabi/5_2-2015q4/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: changing start of section .heap by 4 bytes
c:/users/david/appdata/local/arduino15/packages/sandeepmistry/tools/gcc-arm-none-eabi/5_2-2015q4/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: changing start of section .stack_dummy by 4 bytes
c:/users/david/appdata/local/arduino15/packages/sandeepmistry/tools/gcc-arm-none-eabi/5_2-2015q4/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: changing start of section .heap by 4 bytes
c:/users/david/appdata/local/arduino15/packages/sandeepmistry/tools/gcc-arm-none-eabi/5_2-2015q4/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: changing start of section .stack_dummy by 4 bytes
c:/users/david/appdata/local/arduino15/packages/sandeepmistry/tools/gcc-arm-none-eabi/5_2-2015q4/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: changing start of section .heap by 4 bytes
c:/users/david/appdata/local/arduino15/packages/sandeepmistry/tools/gcc-arm-none-eabi/5_2-2015q4/bin/../lib/gcc/arm-none-eabi/5.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: changing start of section .stack_dummy by 4 bytes
Sketch uses 26932 bytes (5%) of program storage space. Maximum is 524288 bytes.
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
swd
adapter speed: 10000 kHz
cortex_m reset_config sysresetreq
nrf52.cpu: target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x000008e4 msp: 0x20000400
** Programming Started **
auto erase enabled
Error: Cannot erase protected sector at 0x0
Error: failed erasing sectors 0 to 6
embedded:startup.tcl:454: Error: ** Programming Failed **
in procedure 'program'
in procedure 'program_error' called at file "embedded:startup.tcl", line 510
at file "embedded:startup.tcl", line 454
the selected serial port at file "embedded:startup.tcl", line 454
does not exist or your board is not connected

So maybe the root of the problem is that I need to do something to enable it to erase the protected sector at 0x0? That seems to be the point after which everything falls apart.

mfalkvidd

@NeverDie sorry, the ID doesn't need to be in the softdevice. It needs to be in the code for the black magic probe. Might still not be related though.

mfalkvidd

@NeverDie said in nRF5 Bluetooth action!:

Error: Cannot erase protected sector at 0x0

Could this be related to the readback protection? The video I linked before recommends issuing "monitor erase_mass" to completely reset the device and any protection.

NeverDie

@mfalkvidd said in nRF5 Bluetooth action!:

@NeverDie said in nRF5 Bluetooth action!:

Error: Cannot erase protected sector at 0x0

Could this be related to the readback protection? The video I linked before recommends issuing "monitor erase_mass" to completely reset the device and any protection.

Good one! I have a hunch you may have just cracked the problem.

I see no harm in trying a mass erase before the programming step, so I'll give it a go.

Nca78

@mfalkvidd said in nRF5 Bluetooth action!:

@NeverDie said in nRF5 Bluetooth action!:

Is no one else able to download the files either?

From the forum, no. From hightail, yes.

Direct click fails. But if you press Control key while you click, to open in a new tab, then you should be able to download files from the forum ;)

d00616

@mfalkvidd said in nRF5 Bluetooth action!:

Could this be related to the readback protection? The video I linked before recommends issuing "monitor erase_mass" to completely reset the device and any protection.

This is a simple sketch for mass erasing a nRF5 MCU. Just compile it with the option a SoftDevice is present, when a SoftDevice is present:

#include "nrf.h"

void wait_for_ready()
{
        while (NRF_NVMC->READY == NVMC_READY_READY_Busy) {
        };
}


void setup() {
        // Enable erasing flash
        NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Een << NVMC_CONFIG_WEN_Pos;
        wait_for_ready();

        // Erase Flash and UICR
        NRF_NVMC->ERASEALL = 1;
        wait_for_ready();

        // Disable erasing
        NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Ren << NVMC_CONFIG_WEN_Pos;
        wait_for_ready();

}

void loop() {
}```

NeverDie

You would think that the programmer device would just do a mass erase as part of its standard procedure, though, so it's a bit odd that it would require me to do it manually. The mass erase that Roger Clark did with his Black Magic Probe seemed nearly instant. I don't have a Black Magic Probe though.

In any case, I can't use the above sketch to do ia mass erase because it presumes I can already load a sketch onto the target--i.e. it presumes the fundamental problem is solved already.

What's the preferred way to do a mass erase? I seem to remember seeing a mass erase as an option in one of the Nordic utility softwares, but I don't recall now which one. Anyone happen to know?

NeverDie

Looking further into it, what I may need to first do is UNLOCK the Ebyte module, which appears to be a separate step from mass erasing: https://mcuoneclipse.com/2014/10/05/unlocking-and-erasing-flash-with-segger-j-link/

nRF5 action!

16

11.7k

11.2k

113.0k