Skip to content
  • OpenHardware.io
  • Categories
  • Recent
  • Tags
  • Popular
Skins
  • Light
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Brand Logo
  1. Home
  2. My Project
  3. nRF5 action!
  • Getting Started
  • Controller
  • Build
  • Hardware
  • Download/API
  • Forum
  • Store

nRF5 action!

Scheduled Pinned Locked Moved My Project
1.9k Posts 49 Posters 630.8k Views 44 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • alowhumA Offline
    alowhumA Offline
    alowhum
    Plugin Developer
    wrote on last edited by alowhum
    #1579

    @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.

    Nca78N 1 Reply Last reply
    0
    • T Toyman

      @alowhum did you manage to flash them?

      NeverDieN Offline
      NeverDieN Offline
      NeverDie
      Hero Member
      wrote on last edited by NeverDie
      #1580

      @alowhum said in nRF5 Bluetooth action!:

      Could it be that the EByte chips need the DCDC stuff before they can be connected to?

      No.

      1 Reply Last reply
      0
      • alowhumA alowhum

        @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.

        Nca78N Offline
        Nca78N Offline
        Nca78
        Hardware Contributor
        wrote on last edited by
        #1581

        @alowhum have you tried the menu item to write softdevice ? If I remember well it will unlock the chip and after that you will be allowed to write code to it.

        1 Reply Last reply
        0
        • O Offline
          O Offline
          Omemanti
          wrote on last edited by Omemanti
          #1582

          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.

          1 Reply Last reply
          0
          • alowhumA Offline
            alowhumA Offline
            alowhum
            Plugin Developer
            wrote on last edited by
            #1583

            @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.

            YveauxY T M 3 Replies Last reply
            0
            • M Offline
              M Offline
              maciekczwa
              wrote on last edited by
              #1584

              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

              O 1 Reply Last reply
              0
              • alowhumA 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.

                YveauxY Offline
                YveauxY Offline
                Yveaux
                Mod
                wrote on last edited by
                #1585

                @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.

                http://yveaux.blogspot.nl

                1 Reply Last reply
                0
                • alowhumA 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.

                  T Offline
                  T Offline
                  Toyman
                  wrote on last edited by Toyman
                  #1586

                  @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)

                  Mars WarriorM 1 Reply Last reply
                  0
                  • T Offline
                    T Offline
                    Toyman
                    wrote on last edited by Toyman
                    #1587

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

                    1 Reply Last reply
                    0
                    • O Offline
                      O Offline
                      Omemanti
                      wrote on last edited by
                      #1588

                      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.

                      NeverDieN 1 Reply Last reply
                      0
                      • O 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.

                        NeverDieN Offline
                        NeverDieN Offline
                        NeverDie
                        Hero Member
                        wrote on last edited by NeverDie
                        #1589

                        @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.

                        O 1 Reply Last reply
                        0
                        • NeverDieN 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.

                          O Offline
                          O Offline
                          Omemanti
                          wrote on last edited by Omemanti
                          #1590

                          @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 :)
                          0_1524929354866_IMG_20180428_172244.jpg

                          NeverDieN 1 Reply Last reply
                          0
                          • O 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 :)
                            0_1524929354866_IMG_20180428_172244.jpg

                            NeverDieN Offline
                            NeverDieN Offline
                            NeverDie
                            Hero Member
                            wrote on last edited by
                            #1591

                            @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.

                            O 1 Reply Last reply
                            0
                            • NeverDieN 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.

                              O Offline
                              O Offline
                              Omemanti
                              wrote on last edited by
                              #1592

                              @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..

                              Nca78N 1 Reply Last reply
                              0
                              • O 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..

                                Nca78N Offline
                                Nca78N Offline
                                Nca78
                                Hardware Contributor
                                wrote on last edited by
                                #1593

                                @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.
                                0_1524939172574_bt832_antenna.jpg

                                O 1 Reply Last reply
                                0
                                • Nca78N 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.
                                  0_1524939172574_bt832_antenna.jpg

                                  O Offline
                                  O Offline
                                  Omemanti
                                  wrote on last edited by Omemanti
                                  #1594

                                  @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.

                                  0_1524940088510_IMG-20180425-WA0013.jpeg

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

                                  NeverDieN 1 Reply Last reply
                                  1
                                  • alowhumA 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.

                                    M Offline
                                    M Offline
                                    maciekczwa
                                    wrote on last edited by maciekczwa
                                    #1595

                                    @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:)

                                    1 Reply Last reply
                                    1
                                    • alowhumA Offline
                                      alowhumA Offline
                                      alowhum
                                      Plugin Developer
                                      wrote on last edited by
                                      #1596

                                      @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).

                                      1 Reply Last reply
                                      0
                                      • O 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.

                                        0_1524940088510_IMG-20180425-WA0013.jpeg

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

                                        NeverDieN Offline
                                        NeverDieN Offline
                                        NeverDie
                                        Hero Member
                                        wrote on last edited by
                                        #1597

                                        @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.

                                        O 1 Reply Last reply
                                        0
                                        • NeverDieN 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.

                                          O Offline
                                          O Offline
                                          Omemanti
                                          wrote on last edited by Omemanti
                                          #1598

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

                                          1 Reply Last reply
                                          2
                                          Reply
                                          • Reply as topic
                                          Log in to reply
                                          • Oldest to Newest
                                          • Newest to Oldest
                                          • Most Votes


                                          15

                                          Online

                                          11.7k

                                          Users

                                          11.2k

                                          Topics

                                          113.0k

                                          Posts


                                          Copyright 2019 TBD   |   Forum Guidelines   |   Privacy Policy   |   Terms of Service
                                          • Login

                                          • Don't have an account? Register

                                          • Login or register to search.
                                          • First post
                                            Last post
                                          0
                                          • OpenHardware.io
                                          • Categories
                                          • Recent
                                          • Tags
                                          • Popular