nRF5 action!
-
@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.cfgThis started the OpenOCD server. Then I opened another terminal window and did
telnet localhost 4444Now 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 haltedThis 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 infoHere is says "target not protected".
> nrf52.cpu curstate resetWeird: 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 3333But 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.htmlI also got out my voltmeter. Pin 21 and pin 25 have 3v on them, the rest don't.
-
@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.cfgThis started the OpenOCD server. Then I opened another terminal window and did
telnet localhost 4444Now 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 haltedThis 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 infoHere is says "target not protected".
> nrf52.cpu curstate resetWeird: 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 3333But 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.htmlI also got out my voltmeter. Pin 21 and pin 25 have 3v on them, the rest don't.
-
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. -
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.@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 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.
-
@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 :)
-
@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.
-
@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..
@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 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.
@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
-
@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.cfgThis started the OpenOCD server. Then I opened another terminal window and did
telnet localhost 4444Now 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 haltedThis 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 infoHere is says "target not protected".
> nrf52.cpu curstate resetWeird: 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 3333But 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.htmlI also got out my voltmeter. Pin 21 and pin 25 have 3v on them, the rest don't.
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.cfgConnected with telnet to port 4444
Commands:nrf52.dap apreg 1 0x0c nrf52.dap apreg 1 0x04 0x01 resetI 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 watchpointsGood luck with unlocking your modules:)
-
@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).
-
@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
-
@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.
-
@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. -
@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)
-
@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)
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.
-
-
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.
@omemanti said in nRF5 Bluetooth action!:
- 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.
That's what I suggested earlier but it seems it didn't work. But I don't remember if it was with an stlink.
-
-
@alowhum
maybe a very stupid question, but did you check all the wires and after that if your computer uses the right drivers.I took me quite a while to figure this out myself. Especially the driver part messes things up. Errors everywhere that referred to different problems, but after I used Zadig they all disappeared.
-
@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)
@mars-warrior said in nRF5 Bluetooth action!:
@Omemanti and @NeverDie are using these modules, so should be able to write something up that works for other ppl
As I've said many times previoiusly, I use the nRF52 DK to program external modules, and it's what I recommend for noobs because it's relatively hassle free. If you're able to use the $2 st-link v2 programmer then great, my hat's off to you. If not, I recommend the nRF52 DK rather than get frustrated and give up.
