nRF5 action!
-
140$ it is quite expensive compared with a simple small oven
#192 Aldi Hack: Simplify SMD Soldering with a Cheap Aldi Oven. Nothing else – 06:09
— Andreas Spiess -
Quick question: when programming the eByte module (or any module really):
Should I select "reset enable or not? What does that do exactly?
Should I select clock: "Crystal oscillator" for the eByte module? -
Quick question: when programming the eByte module (or any module really):
Should I select "reset enable or not? What does that do exactly?
Should I select clock: "Crystal oscillator" for the eByte module? -
Quick question: when programming the eByte module (or any module really):
Should I select "reset enable or not? What does that do exactly?
Should I select clock: "Crystal oscillator" for the eByte module? -
Thanks!
I received two new eByte modules. I can't even connect to either one, both with BMP or ST-Link V2. Very strange. I'm going to try not powering them from the USB stick but from a second 3.3v source.
-
Thanks!
I received two new eByte modules. I can't even connect to either one, both with BMP or ST-Link V2. Very strange. I'm going to try not powering them from the USB stick but from a second 3.3v source.
-
@toyman No. I don't understand what's going on, as I was able to flash one succesfully before. I did find [this a bit unnerving].(https://devzone.nordicsemi.com/f/nordic-q-a/19943/nrf52832-unable-to-connect-to-the-target).
Could it be that the EByte chips need the DCDC stuff before they can be connected to? Or that the exact moment on power-on (reset) matters?
One thing I have found is that I had installed OpenOCD on my laptop to turn a ST-Link V2 into a Black Magic Probe. That version of OpenOCD was overruling the hacked version that Sandeep Mistry had created for the NRF5.
But even with that removed, the problem remains this:
"TARGET: nrf52.cpu - Not halted".
Apparently this is a sign that the chips are protected. I was able to remove that protection before (by selecting "Burn Bootloader"), but it doesn't work now.
-
@alowhum said in nRF5 Bluetooth action!:
Could it be that the EByte chips need the DCDC stuff before they can be connected to?
No.
-
@toyman No. I don't understand what's going on, as I was able to flash one succesfully before. I did find [this a bit unnerving].(https://devzone.nordicsemi.com/f/nordic-q-a/19943/nrf52832-unable-to-connect-to-the-target).
Could it be that the EByte chips need the DCDC stuff before they can be connected to? Or that the exact moment on power-on (reset) matters?
One thing I have found is that I had installed OpenOCD on my laptop to turn a ST-Link V2 into a Black Magic Probe. That version of OpenOCD was overruling the hacked version that Sandeep Mistry had created for the NRF5.
But even with that removed, the problem remains this:
"TARGET: nrf52.cpu - Not halted".
Apparently this is a sign that the chips are protected. I was able to remove that protection before (by selecting "Burn Bootloader"), but it doesn't work now.
-
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.06I 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.
-
@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.
-
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 -
@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 :)
