nRF5 action!

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/

Toyman

@NeverDie may be some hints here:
https://learn.adafruit.com/bluefruit-nrf52-feather-learning-guide/flashing-the-bootloader

And also pay attention to their Adalink tool. The support for nrf52 was added recently.

NeverDie

By switching to a Windows 10 computer, I was able to get J-link working over USB from windows. Then I opened up J-Link Command, which mostly utiizes a command line interface. It turns out that for unlocking, the nRF52836 is not on the list of devices (see below), so I simply then issued a mass erase command, which looks as though it may have worked:

J-Link>unlock
Syntax: unlock <DeviceName>
---Supported devices---
  LM3Sxxx [<Auto>]
  Kinetis
  EFM32Gxxx
  LPC5460x
J-Link>erase
Erasing device (nRF52832_xxAA)...
J-Link: Flash download: Total time needed: 0.336s (Prepare: 0.064s, Compare: 0.000s, Erase: 0.263s, Program: 0.000s, Verify: 0.000s, Restore: 0.008s)
Erasing done.
J-Link>mem 0 100
00000000 = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
00000010 = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
00000020 = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
00000030 = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
00000040 = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
00000050 = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
00000060 = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
00000070 = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
00000080 = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
00000090 = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
000000A0 = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
000000B0 = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
000000C0 = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
000000D0 = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
000000E0 = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
000000F0 = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
J-Link>

:)

NeverDie

I received the following message from the Ebyte seller:

Sorry that the two files are incorrect, please just ignore or delete them.
We will send correct files later.

Thank you!

NeverDie

It worked! After doing the above mass erase, the nRF52832 Ebyte Module successfully programmed from the NRF52 DK. I uploaded the mysensors lightsensor sketch, and the serialGateway running on the NRF52 DK is receiving its messages. :)

Many thanks to mfalkvidd for his mass erase suggestion and for his link to the Roger Clark youtube video, which had further mass erase commentary.

Also, many thanks to d00616 for his excellent guide:
https://www.openhardware.io/view/376/MySensors-NRF5-Platform
Without that, I would have been lost on how to set anything up.

Thanks to everyone else too who made comments and suggestions. This has been a great group effort with a successful outcome. :) :) :)

nRF5 action!

12

11.7k

11.2k

113.0k