Hello
I have two feather boards BRD-0015-05
Both of them i’m able to program by newtmgr but i’m not able to the same by SWD.
I’m sure my system is working like it should and connection with board and programmer is good as well.

Here is output from nrfjprog:
nrfjprog -r
[error] [ Client] - Encountered error -102: Command connect_to_emu_with_snr executed for 414 milliseconds with result -102
ERROR: Unable to connect to a debugger.
[error] [ Worker] - An unknown error.
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.
NOTE: For additional output, try running again with logging enabled (–log).
NOTE: Any generated log error messages will be displayed.
Best Regards

    @devitwise can you share how you have your external programmer and Tag Connect cable attached to your boards? I recommend powering the board with battery or USB power when external programming as well.

    All boards are loaded with test firmware and modem firmware from the factory using an external JLink board.

      jaredwolff
      Everything is the same like in your guideline: https://docs.circuitdojo.com/nrf9160-programming-and-debugging.html
      I check it few times. The board is powered by USB, as programmer i use nrf53dk or JLINK edu mini.

      Also i tested this programmer configuration with thingy91 ant it works.
      To the one of the boards i solder wires to make sure the connection i good and there is no changes.

      Also i tried to establish connection in Bootloader mode but not help.

          Can you share the output of the commands you’re running? Please also share a picture of your setup.

            Sure
            I have only the soldered board without cable, but this should not be a problem.
            I using Reset, VCC, GND from soldered pins. SWDIO and SWCLK are soldered to TP1 and TP2.
            The last photos are signal waveforms for the command:
            nrfjprog –reset
            Response:
            [error] [ Client] - Encountered error -102: Command connect_to_emu_with_snr executed for 753 milliseconds with result -102
            ERROR: Unable to connect to a debugger.
            [error] [ Worker] - An unknown error.
            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.
            NOTE: For additional output, try running again with logging enabled (–log).
            NOTE: Any generated log error messages will be displayed.







              Sorry, but my instructions involve using a tag connect TC2030-CTX-NL not wiring directly to the board.

              I have modified the development kits in the past using the 0.1” header connection toward the middle of the board. Make sure that you’re providing power to that specific SWD interface otherwise it won’t “select” it.

              I’m currently traveling right now but I can share a picture of my modified programming rig when I get back in a few days.

              as programmer i use nrf53dk or JLINK edu mini.

              I don’t see a nRF53, for me this looks like a nRf9160-DK.

              Also i tested this programmer configuration with thingy91 ant it works.

              Please be careful, as the Thingy:91 uses a 1.8V for VDD IO (and so the nRF9160-DK must be switched (SW9) to use 1.8V as well), but the feather uses 3.3V VDD IO (and so the nRF9160-DK must be switched (SW9) to use 3.0V).

              using a tag connect TC2030-CTX-NL

              Considering, that at least others time is also money, the 60* $ for that connector isn’t that much . If you’re not located in the US, some resellers (e.g. digikey) may help. You may also order one “with Legs” (TC2030-CTX, the NL is for No Legs) and cut the legs off.

              (* 60$ the price seems to have been raised. Maybe a reason to switch in the future to the 10 pin headers.)


                AchimKraus 100% agree here. The Tag Connect has proven to be a pain point for everyone. Thanks for weighing in

                    jaredwolff
                    Agreed. I have and use the Tag Connect but prefer the Mini SWD 10 pin headers for dev boards.

                    Your next generation nRF9161 Feather, likely running a version of the Raspberry Pi Debug Probe CMSIS-DAP SWD/UART on the RP2040 is a neat solution. Although, I don’t think the DebugProbe firmware currently has RTT support. I suspect Segger could easily support a J-Link OB for RP2040 (like nRF52840 , nRF5340) but licence fees will come into play.

                        zpm1066 Although, I don’t think the DebugProbe firmware currently has RTT support.

                        That’s why there’s a dedicated flow control UART between the RP2040 and nRF9161 😉 Gotta get that console output somehow!

                            jaredwolff Curious, Did you consider licensing Segger J-Link OB firmware and using a nRF5340 or nRF52840? Depending on your board quantities, If the license fees are only a few dollars then probably worth it.

                            I expect the Raspberry Pi DebugProbe will gain RTT, as it’s on their todo list.

                                @zpm1066 I honestly would like to use/support open source projects rather than J-Link. I’ve also never seen the firmware used on a nRF52 before. Only devices I’ve ever seen run it are ATMega parts.

                                Added note:

                                Looks like they support some Renesas, NXP and STM parts as well. ($$$)

                                  jaredwolff Agreed regarding supporting open source projects.
                                  A few years back, I came across a couple of bugs in the BBC micro:bit v2 Segger J-link OB. Segger were reluctant to fix them as the micro:bit v2 J-link OB isn’t a revenue stream for them. Of course, if I had access to their code, fixes would have been pretty straight forward. So, at least for open source, we can make quick fixes and enhancements.

                                    100%. I love the option to directly contribute (code & monetarily) to the projects. Especially if they’re shaking up the current paradigm (J-Link hegemony!)

                                      In my experience (about 10 years Eclipse/Californium and Eclipse/tinydtls) you need to focus on the things, you want to achieve. So, if it’s about providing a open source alternative development chain, then this RP2040 may be a good step.
                                      I my self focus on the “Things” running in the internet (OK, obvious with working on Californium and tinydtls). And with that, I don’t want to spend time in a development chain. To be frank, I don’t have that time.

                                      Terms and Conditions | Privacy Policy