[SOLVED] LCP645xx: J-Link fails to connect via SWD on custom boards

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • [SOLVED] LCP645xx: J-Link fails to connect via SWD on custom boards

    I'm working on two different prototypes of two different boards with two different MCUs of the same family: LPC54618 and LPC54628 by NXP.

    Initially J-Link is able to make a good connection via SWD and I can download new firmware, debug and so on.

    However, it happened two times (the first with one board and the second on another board) that J-Link wasn't able to connect to the MCU anymore. In the first case, I mount a completely new PCB (with a new MCU) and now it is working well, but the original MCU seems bricked.
    In the second case, I decided to replace the MCU on the board, but the error is still there: J-Link can't connect via SWD.

    After some tests, I understood that the MCU is fully functional: the application that resides in the Flash runs without any problem. I'm also able to enter ROM UART Bootloader via ISP pins and I'm able to download a new firmware via UART.

    It seems only SWD port/pins is locked, but I don't know why.

    I investigated ECRP (a method from NXP that enables some restrictions on the MCU, i.e. SWD access), but it seems all is allowed and unlocked.

    I already asked NXP guys, but without success at the moment. I write here, maybe it's something related to J-Link and not NXP.
  • Hi,
    Thank you for your inquiry.

    In 99% of the cases where such a problem appears,
    the target application itself may run fine but it is uncooperative in regards to debugging.
    Usually such a Problem is connected to one of the three following points.
    The application
    1) re-configures the debug pins as GPIOs.
    2) enables chip security (by accident or on purpose)
    3) makes use of low-power modes that disable all debug related clocks inside the chip.
    All the above prevent a debug connection to the device.

    Especially the part that things are initially working but then stop working at some point,
    after playing with the application / modifying it for a while, are often an indicator for #1 or #3.

    However, replacing the MCU should solve the issue.
    If you are sure that the replaced MCU is soldered correctly on the PCB, I would advice to check if the signals between MCU and debug header are actually connected through.
    Maybe the lanes on the PCB were damaged or some peripheral is active that influences the signal integrity of the debug lanes.

    BR
    Fabian
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Fabian wrote:

    Usually such a Problem is connected to one of the three following points.
    The application
    1) re-configures the debug pins as GPIOs.
    I think this is not my case for a simple reason. I can enter ROM Bootloader by keeping low one ISP bootstrap pin. When in Bootloader, my application doesn't run at all. However, even when the ROM Bootloader is active, SWD doesn't work (while on EVB I can connect through SWD during Bootloader).

    Fabian wrote:

    2) enables chip security (by accident or on purpose)
    At the beginning I was thinking of this. LPC546XX has a method, called ECRP, that could lock SWD access by a magic work in Flash or writing some bits in OTP memory. However I can erase entire Flash (through UART ROM Bootloader) and the bits in OTP memory seems at their default values (identical to EVB).

    Fabian wrote:

    3) makes use of low-power modes that disable all debug related clocks inside the chip.
    Not in my case, when I enter ROM Bootloader.

    Fabian wrote:

    If you are sure that the replaced MCU is soldered correctly on the PCB, I would advice to check if the signals between MCU and debug header are actually connected through.
    Maybe the lanes on the PCB were damaged or some peripheral is active that influences the signal integrity of the debug lanes.
    Yes, MCU is soldered correctly because I can see SWDIO and SWCLK pins toggling (directly on the debug header connector) when the application re-configures them as GPIO.

    I don't know what to think.
  • Hello Fabian,

    I know it's incredible, but three times I experienced this problem on three differrent PCBs and MCUs: LPC54101, LPC54618 and LPC54606. J-Link returns the error "Could not connect to target", it seems SWD access is locked on the MCU.

    I don't know what's the problem is, but I'm starting thinking of the J-Link that could be malfunctioning (even if it works great with other boards and MCUs).

    I have the latest J-Link software and I tried to restart from a blank project, without any success.

    In all three cases, I am able to enter USART ISP Boot and erase internal Flash memory, but SWD access again is impossible even after chip erase.

    Could be the J-LINK malfunctioning and destroy SWD of connected MCUs?
  • After some investigations, I found something interesting on SWDIO pin. When the probe is able to connect to the MCU, SWDIO signal goes high and low without problems: I can see 0V and Vcc on scope.
    On MCUs that are broken, SWDIO swings in a more restricted voltage range: for example from 1V to 2V.

    It seems SWDIO is broken inside MCU, but this happend THREE times! Is it possible that J-Link is responsible for this? Is it possible that a malfunctioning J-Link could apply a somewhat high voltage on SWD lines during programming?

    I'm thinking that J-Link could be the cause of all these issues because they happened recently three times with three different MCUs and three different custom boards. I used this J-Link probe for many years without any problems on many MCUs, but recently I have all these issues.
  • Hi,
    I highly suspect that this is connected to your hardware.
    We did not receive a single other report of such a case happening.
    Does the same issue appear when using an evaluation board?

    The J-Link uses the voltage between VDD and GND (VTref) as reference voltage for the communication.
    I would suggest to measure the voltage between VDD and GND and compare it to the evaluation board.
    Also, you could connect an oscilloscope to the SWD signals to check and compare them with VTref.
    If there is indeed a voltage problem on J-Link side, please let us know.

    So far, we have not had a single report about a malfunctioning J-Link that caused overvoltage on device side.

    Could you please check this?

    BR
    Fabian
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • SEGGER - Fabian wrote:

    I highly suspect that this is connected to your hardware.
    Ok, but this happened on three different boards. If there's a problem on my hw, it is repetitive on multiple boards and MCUs.
    This isn't the first board we design, we don't explain what is happening.

    SEGGER - Fabian wrote:

    Does the same issue appear when using an evaluation board?
    Until now no, I have these issues only on custom boards. Anyway they are very similar to EVB, at least for SWD lines connection.
    Only LPC546xx EVB has protection diodes on SWD lines, while I don't have them on my custom board.


    SEGGER - Fabian wrote:

    I would suggest to measure the voltage between VDD and GND and compare it to the evaluation board.
    It's 3.3V as normal.

    SEGGER - Fabian wrote:

    Also, you could connect an oscilloscope to the SWD signals to check and compare them with VTref.
    On boards that mount good MCUs, SWD lines swing normally between GND and VDD. As I wrote, if I connect broken MCUs, SWDIO line isn't able to go to GND and to VDD. Look at the picture attached. The upper trace is VDD, while the lower trace is SWDIO. The reference for both channels are at the same point. It's evident there's some problem with SWDIO.he problem is inside MCU.

    I suspect something has broken inside the MCU on SWD lines, but only J-Link is attached to these lines.
  • Hi,
    Could you please tell us the serial number of the J-Link you are using?

    BR
    Fabian
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • 50116485

    However we are testing ground connections. We measured around 20Vac between board ground and J-Link ground, before connecting them.

    I'm suspecting that the problem can arise when I hot-plug J-Link flat cable to the board.

    The board is supplied from an AC/DC with its metallic case connected to earth and the reference of its output +12Vdc is connected to earth too. The PC is a standard desktop computer connected to a UPS.
    I don't know why there's such a residual alternate voltage, most probably caused by mains 230Vac.

    I make a good connection between metallic case of my desktop PC and metallic case of AC/DC that powers the board and now I don't see 20Vac residual voltage anymore. Maybe this could be the cause of my issues.

    What do you suggest to have a good workbench in this scenario?
  • Hi,
    This would absolutely explain the issue.
    Please note that these voltage differences can also damage the J-Link.
    In case your J-Link was damaged, you could make use of the SEGGER Trade-In Program:
    segger.com/purchase/trade-in-program/

    To prevent such kind of damage caused by ground loops or similar, we recommend to use an isolator between J-Link and target:
    segger.com/products/debug-prob…tors/j-link-swd-isolator/

    BR
    Fabian
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.