Cart New Account Login

HomeAbout usProductsSupportForumsBlogCustomer Service

search inside this forum
search inside all forums
SWD comm failure with MultilinkFX
Lars W. Feb 9, 2020 at 11:39 AM (11:39 hours)
Staff: Mika I.

  • Hello, I am trying to connect my MultilinkFX with an iMXRT1064 based custom board, MIMXRT1064DVL6A, but having problems connecting with MCUXpresso.
    The error I get is "...The GDB server was not able to establish a connection to the target processor..."
    I have updated the drivers and checked the cable connections etc.
    Looking with the scope on the signals there is a lot of activity on SWD and SWCL that is consistent with what should be expected. I refer to the document"ARM Debug Interface Architecture Specification ADlv5.0 to ADlv5.2.

    '-' = delay.
    The first communication sequence is:
    1. A long series of clock signals with SWD high (1111-1111-1111-11).
    2. The JTAG-SWD sequence: 0111100111100111.
    3. Delay of 800 mS.
    4. This I think is an SWD read operation: 10100101-1-001-1101 1100 0101 0001 0001 0111 1010 0001.

    It is followed by a number of similar operations during a few seconds before the debug dialogue gives the error message.
    Unfortunately, I don't seem to be able to upload any screenshots from the scope here in the forum.

    From the above data, do you see that the processor is responding in 2 above?

    Is there some test I can do to try and figure out what is preventing the probe to understand the processor?

    The MultilinkFX I have is a few years old but I suppose it should work well when correctly updated?

    I appreciate any suggestions to get the SWD communication working.



  • Hi Lars,

    Thank you for providing that information.

    First, please make sure that you have our latest GDB server plug-in installed.

    Download the plug-in here:

    Follow our step-by-step instructions here:

    Best Regards,

  • Hi Mika,

    Thank you for your advice, we have updated versions of all software and drivers.

    The problem is identified and was not the PEMicro but faulty (or locked in sleep cycle) hardware.



  • Hi Lars,

    Thanks for the update. I'm glad you've identified the issue!


Add comment

   Want to comment? Please login or create a new PEmicro account.

© 2021 P&E Microcomputer Systems Inc.
Website Terms of Use and Sales Agreement