nRF5 action!

Omemanti

~~Hey,~~

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

~~I changed: MyBoardNRF.h and included nrf.h~~

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

~~but somehow the TX pin stays P0.25.~~

~~Can someone point me in the right direction?~~

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

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

alowhum

@Nca78 Thanks, but it didn't work either :-(

Some notes from my adventures with the eByte module:

I've been playing with OpenOCD and the ST-Link v2. The ST-Link V2 that I turned into a Black Magic Probe doesn't see the modules.

I went into the Arduino's folder that has OpenOCD, created .cfg file, and then:

./openocd -d2 -f nrf52832.cfg

This started the OpenOCD server. Then I opened another terminal window and did

telnet localhost 4444

Now I could manually issue some OpenOCD commands. The goal was to do a manual mass erase.

Some OpenOCD commands and their output:

flash probe 0                                                                 c Unknown device (HWID 0x00000000)

> flash banks
#0 : nrf52.flash (nrf51) at 0x00000000, size 0x00000000, buswidth 1, chipwidth 1
#1 : nrf52.uicr (nrf51) at 0x10001000, size 0x00000000, buswidth 1, chipwidth 1

> flash probe 1
Unknown device (HWID 0x00000000)
flash 'nrf51' found at 0x10001000

> nrf51 mass_erase 0
Target not halted

This command actually resulted in OpenOCD ballooning to 8Gb in ram. Then after 5 minutes of seemingly being busy, I got the 'target not halted' command.

> flash info 1
Unknown device (HWID 0x00000000)
#1 : nrf51 at 0x10001000, size 0x00000100, buswidth 1, chipwidth 1
	#  0: 0x00000000 (0x100 0kB) not protected
Target not halted
error retrieving flash info

Here is says "target not protected".

> nrf52.cpu curstate
reset

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

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

telnet localhost 3333

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

The OpenOCD documentation mentions the chip protection:

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

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

maciekczwa

I have the same problem with brand news ebyte modeules.

Here are my openocd logs:

Open On-Chip Debugger 0.10.0-dev-gdc53227 (2016-04-09-13:45)
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 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
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
wybrany port szeregowy at file "embedded:startup.tcl", line 454
nie istnieje albo Twoja płytka nie jest podłączona

Yveaux

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

Not sure if this is related to your issue, but it's worth a try.

Toyman

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

Toyman

another method (although I haven't tried it with Ebyte) is to use BMP with GDB and issue a "erase mass" command

Omemanti

Is there a way to enhance the sending performance of the Ebyte units?

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

NeverDie

@omemanti said in nRF5 Bluetooth action!:

Is there a way to enhance the sending performance of the Ebyte units?

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

Omemanti

@neverdie, I did some digging and cut a part of my PCB that was grounded. range drastically increased, guess I need to order a new prototype :)

NeverDie

@omemanti Ah, that makes sense. That's why on my PCB's I have the antenna portion of the module hanging over the edge of the PCB into empty space.

Omemanti

@neverdie said in nRF5 Bluetooth action!:

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

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

Nca78

@omemanti said in nRF5 Bluetooth action!:

@neverdie said in nRF5 Bluetooth action!:

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

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

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

Omemanti

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

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

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

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

maciekczwa

@alowhum

Hi I managed to clear the access protection.

I connected ebyte module directly to raspberry pi.

I used this guide http://hivetool.org/w/index.php?title=BMD301 with little modifications

Compiled openocd - current version - 7b94ae9e520877e7f2341b48b3bd0c0d1ca8a14b

Added chip definition - I don't know if it is needed, I can check that - I have more modules to unlock

diff --git a/src/flash/nor/nrf5.c b/src/flash/nor/nrf5.c
index 31dd5aae..e01d7ddf 100644
--- a/src/flash/nor/nrf5.c
+++ b/src/flash/nor/nrf5.c
@@ -204,6 +204,7 @@ static const struct nrf5_device_spec nrf5_known_devices_table[] = {

 	/* nRF52832 Devices */
 	NRF5_DEVICE_DEF(0x00C7, "52832", "QFAA", "B0",    512),
+	NRF5_DEVICE_DEF(0x00C7, "52832", "QFN48", "B00",    512),
 };

 static int nrf5_bank_is_probed(struct flash_bank *bank)

Started openocd:

openocd -f interface/raspberrypi-native.cfg -c "transport select swd; set WORKAREASIZE 0" -f target/nrf52.cfg

Connected with telnet to port 4444
Commands:

nrf52.dap apreg 1 0x0c
nrf52.dap apreg 1 0x04 0x01
reset

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

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

Good luck with unlocking your modules:)

alowhum

@maciekczwa said in nRF5 Bluetooth action!:

nrf52.dap apreg 1 0x0c

Thanks for the tip! Unfortunately ST-Link V2 gives:

> nrf52.dap apreg 1 0x0c
invalid command name "nrf52.dap"

(same with just "dap", which I had tried earlier).

NeverDie

@omemanti That PIR sensor lens sure has a small footprint. I'll be interested to hear how well it performs and whether you like it or not.

Omemanti

@neverdie it's the AM612, and in the little tests I did so far, it did great.

alowhum

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

nrfjprog --recover
ERROR: JLinkARM DLL reported an error. Try again. If error condition
ERROR: persists, run the same command again with argument --log, contact Nordic
ERROR: Semiconductor and provide the generated log.log file to them.

I tried lots of DLL versions, and a new version of nrfjprog.. no luck.

nrfjprog --recover --log
nrfjprog verion 9.7.0
--------------------------------------------------------------------------------
FUNCTION: open_dll.
FUNCTION: open_dll.
FUNCTION: enum_emu_snr.
FUNCTION: enum_emu_snr.
FUNCTION: enum_emu_snr.
FUNCTION: enum_emu_snr.
FUNCTION: connect_to_emu_with_snr.
FUNCTION: connect_to_emu_with_snr.
FUNCTION: connect_to_emu_without_snr.
FUNCTION: enum_emu_snr.
Device "NRF52832_XXAA" selected.
FUNCTION: read_connected_emu_snr.
FUNCTION: read_connected_emu_snr.
FUNCTION: read_device_family.
FUNCTION: read_device_family.
JLinkARM.dll CORESIGHT_WriteAPDPReg returned error -1.
JLinkARM.dll CORESIGHT_WriteAPDPReg returned error -102.
FUNCTION: close_dll.
FUNCTION: close_dll.

Mars Warrior

@alowhum, you seem to need Jlink Commander:

@toyman said in nRF5 Bluetooth action!:

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

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

(My ebyte modules are still on their way)

Omemanti

@mars-warrior @alowhum

For uploading code onto the Ebyte modules I use an ST-Link V2 (2 dollar USB modules).

Install the USB-Driver using Zadig
Connect the DIO, CLK VCC, and GND.
For testing purposes, I soldered just the tips of some Dupont cables to the Ebyte module and put the female parts on the ST-link.
The first time I want to upload code, I first "burn the bootloader" (Tools => burn Bootloader) (https://forum.mysensors.org/topic/6961/nrf5-bluetooth-action/386)
This will give an error.
After that, you should be able to upload sketches.

nRF5 action!

13

11.7k

11.2k

113.0k