Programming Custom nRF5340 PCB via J-Link Interface defies laws of physics?

Hi, I am seeking assistance with a very weird issue encountered while programming an nRF5340 SoC using a custom debugging-PCB using a SEGGER J-Link EDU debugger.

The debugging PCB is designed to plug directly into the J-Link (and the board featuring the nRF5340 plugs into this board).

The nRF appears in VS Coder under connected devices, but attempts to flash the device result in the following error:

HOWEVER, when the debugging PCB is not plugged directly into the J-Link, but each pin is individually connected to the J-Link using jumper wires, programming proceeds without issues.

I've narrowed down the issue to the SWCLK line: connecting the debugging PCB directly and soldering a 5 cm jumper wire between the SWCLK pins solves the issue.

This doesn't work:

This does work: 

This doesn't work again:

Troubleshooting Steps Undertaken:

1. Measured the resistance of the connecting cable, which is approximately 0.5 Ω

2. Introduced resistors ranging from 0.5 ohms to 200 Ω in series with each J-Link pin (especially SWCLK to simulate the jumper wire resistance); this did not resolve the issue.

3. I noticed that probing the SWCLK line with an oscilloscope prevents successful flashing, indicating sensitivity on this line.

4. Implemented external pull-up and pull-down resistors for SWDIO and SWCLK , as well as low-pass filters, without achieving successful programming.

5. Built an "extension" plug that plugs directly into the J-Link and then in the debugging PCB, then it doesn't work. If the debugging board is not entirely plugged in all the way (leaving some millimetres while ensuring all lines are connected, it works....

When probing the lines with an oscilloscope, you can see a bit of ringing, but the signal is the same if probed with jumper wire extensions or without, so this can't be the issue, right?

TLDR: I'm literally clueless at this point. All my colleagues have looked over the schematics, we ruled out any issues we've come up with, it just doesn't work, when there's a direct connection, it works when there a jumper wire in the SWCLK line

I appreciate any insights or recommendations from the community to resolve this weird bug

Parents
  • Hi,

    Could you share the schematics and layout files? You can share it as a PDF and Gerber files.

    I can make the case private first if you prefer it.

    regards

    Jared 

  • We can keep this public, it's an open source project anyway. I've attached the schematics and gerber files. Please let me know when you need anything else. The board we're trying to flash also has a DSP, that's why we have this switch on the debugging PCB. But that should not cause any problems, right?

     Debugging_PCB.zip

  • Hi,

    Can you try to solder some wires that is connected directly to the pads of the nRF5340 + VDD and GND and see if you are able to program it?

    regards

    Jared 

  • I'm not sure I'm correctly understanding what you're referring to. Soldering wires to the nRF5340 directly onto the debugging PCB? Or trying whether I can program it at all? Because this works, just not with this custom PCB. Could you please clarify what I can try? Thank you! 

  • Hi,

    I'm sorry for the confusion. To be clear, I'm interested in knowing whether this is an issue with your PCB design or it's an issue with the IC itself. Based on your description, it seems like the issue is due to PCB design, but to be sure I wanted you to connect directly to the SWD pads and see if you are able to program the chip consistently . 

    It would also be interesting if you could provide trace of SWDIO, and SWDCLK when it works versus when it doesn't work. Is there any obvious change in the CLK or data signal?

    regards

    Jared 

  • Thank you for the clarification! When connecting to the SWD pads directly, I can consistently program the chip. I can't really provide you with traces, because as soon as I probe the line, it doesn't work program anymore..

  • Hi Lepold, 
    Jared is away this week and will be back next week. 
    My understanding is that when you connect the programmer to the board with cable instead of connecting directly to the header it worked. 
    You would need to take a deeper look into the header you use. Is there any chance that something is shorted ?
    Test on all single pin to see if any thing is shorted. 
    My personal experience with SWD is that it's not a high speed communication so it's quire resilient to interference so more chance that there is something shorted somehow. 
    Please also try supply the board/chip with external power supply. I assume you are using a battery ? 

Reply
  • Hi Lepold, 
    Jared is away this week and will be back next week. 
    My understanding is that when you connect the programmer to the board with cable instead of connecting directly to the header it worked. 
    You would need to take a deeper look into the header you use. Is there any chance that something is shorted ?
    Test on all single pin to see if any thing is shorted. 
    My personal experience with SWD is that it's not a high speed communication so it's quire resilient to interference so more chance that there is something shorted somehow. 
    Please also try supply the board/chip with external power supply. I assume you are using a battery ? 

Children
No Data