Cart New Account Login

HomeAbout usProductsSupportForumsBlogCustomer Service

search inside this forum
Multilink Universal FX doesn't work long enough to do anything useful
Rodney S. Apr 5, 2016 at 08:25 PM (20:25 hours)
Staff: Takao Y.

  • When I connect to either KDS or pegdbserver to the hardware it starts updating the firmware, but this almost always fails.

    When the programmer gets through that stage and I try to connect to a hardware device it almost always fails.

    When I have been able to connect to a target MCU it always fails.

    In short, I haven't been able to get the programmer to work.

    I'm targeting an NXP K20DX128M5 on a custom board. I've tried running the programmer in a virtual Ubuntu-15.04 64-bit machine, a virtual 32-bit Windows XP machined, and natively on an opensuse 13.1 64-bit machine.

    I use the following command to start the server:
    /opt/Freescale/KDS_v3/eclipse/plugins/com.pemicro.debug.gdbjtag.pne_2.3.6.201602211227/lin/pegdbserver_console -startserver -device=NXP_K2x_K20DX128M5 -speed=5 -showflashstatus

    The following is a representative sample output when the programmer does configure successfully but fails to connect to the target MCU.

    P&E GDB Server for Arm(R) devices, Version 5.79.00.00
    Copyright 2014, P&E Microcomputer Systems Inc, All rights reserved

    Loading library /opt/Freescale/KDS_v3/eclipse/plugins/com.pemicro.debug.gdbjtag.pne_2.3.6.201602211227/lin/gdi/unit_ngs_arm_internal.so ... Done.

    Command line arguments: -startserver -device=NXP_K2x_K20DX128M5 -speed=5 -showflashstatus
    Device selected is NXP_K2x_K20DX128M5
    HW Auto-Selected : Interface=USBMULTILINK Port=PEME049BB ; USB1 : Multilink Universal FX Rev B (PEME049BB)
    Connecting to target.
    P&E Interface detected - Flash Version 0.00

    (C)opyright 2014, P&E Microcomputer Systems, Inc. (http://www.pemicro.com)



    Loading srec from /opt/Freescale/KDS_v3/eclipse/plugins/com.pemicro.debug.gdbjtag.pne_2.3.6.201602211227/lin/gdi/P&E/usbmlfxufarmens.0941

    Successfully found /opt/Freescale/KDS_v3/eclipse/plugins/com.pemicro.debug.gdbjtag.pne_2.3.6.201602211227/lin/gdi/P&E/usbmlfxufarmens.0941

    Erasing internal application checksum ...

    Rebooting ...

    Erasing Application region ...

    Blank checking Application region ...

    Programming Application firmware ...

    Updating Multilink FX Logic, please wait ...

    Erasing Logic ...

    Programming Logic Main Array ...

    Programming Logic Secondary Array ...

    Verifying Logic Arrays ...

    Failed on verification of Logic Arrays

    Could not contact P&E Hardware Interface. Check Power and Connections.

    Unable to initialize PEDebug.

    PE-ERROR: Failed to Initialize Target
    Target Disconnected.
    Target Disconnected.




    Comments

  • Greetings,

    I see you are trying to start the GDB server remotely from KDS. Have you given it a try to debug without starting a remote session? Have you tried simply creating a project within KDS and without making any changes to code or configurations try to debug your project? I want to know if you are able to get your multilink to firmware update correctly.


    Takao Yamada

    • The first sentence of my problem report states that I had tried using KDS and that the failures to communicate, configure the dongle, and maintain communications were the same as with pegdbserver.

      I have been able to update the firmware. I downloaded the application from the web site and was able to run it successfully on a virtual Windows XP machine, however, the dongle continued to consistently fail the same way it did before the update.

  • Greetings,

    A few questions:

    1) Have you ever gotten this multilink to work at all in other projects or other devices? Is it a problem only on this custom K20DX device? I want to rule out the P&E interface as the problem.

    2) Are you using any custom ribbon cable, adapters, external watchdog, or other unique setup between the multilink and the chip?

    3) Are both blue and yellow LED lit when the multilink is connected to the computer and the board? Blue indicates drivers are good. Yellow indicates it detects power on your board.

    4) Are you using SWD or JTAG? Try out both to see if you get any different result. My belief is that K20DX should work with both in general case, but it may also depend on how the custom board was designed to use.


    Takao Yamada

  • 1) I got the dongle from a Client.  It had been working for them, but that was almost a year ago.

    2) I'm using the 10-strand ribbon cable that came with the dongle

    3) Yes

    4) I'd commanded SWD in KDS. I'm not sure what pegdbserver is doing natively. This doesn't address the frequent failures that appear before the dongle even tries to communicate with the micro controller.

  • Greetings,

    If I understand you correctly, even though you already firmware updated the multilink using the firmware updater utility in the resource CD, you are still seeing the firmware update trying to happen in KDS? What firmware did you update to when using the utility? The latest version is either version 7.09 or version 9.58 depending on the revision you have. You used this download correct?:
    http://www.pemicro.com/downloads/download_file.cfm?download_id=346

    Once you firmware update, you should not need to update again as long as you stay in ARM debugging. The firmware may change if you are switching chip architectures. If you do get past the firmware update log you posted earlier, what other log information are you seeing?


    Takao Yamada

    • I'm seeing the firmware update in KDS and in pegdberver.  I downloaded the update software yesterday, so I'm presuming it was the latest version, at least as of yesterday.  I can't find an e-mail with the download link.

      I'm not switching chip architectures, I've only tried to configure the dongle for the K20 chip.

      When I do get a successful re-configuration, I get the following kinds of messages:

      ===========================================================================
      Invoked with
      .../pegdbserver_console -startserver -device=NXP_K2x_K20DX128M5 -speed=5 -showflashstatus
      It took 3 tries to get to this state
      It Did not attempt to reprogram this time
      yes -- both lights are on
      The connect/disconnect happened when I entered "target remote localhost:7224" in gdb.
      ===========================================================================

      P&E GDB Server for Arm(R) devices, Version 5.79.00.00
      Copyright 2014, P&E Microcomputer Systems Inc, All rights reserved

      Loading library /opt/Freescale/KDS_v3/eclipse/plugins/com.pemicro.debug.gdbjtag.pne_2.3.6.201602211227/lin/gdi/unit_ngs_arm_internal.so ... Done.

      Command line arguments: -startserver -device=NXP_K2x_K20DX128M5 -speed=5 -showflashstatus
      Device selected is NXP_K2x_K20DX128M5
      HW Auto-Selected : Interface=USBMULTILINK Port=PEME049BB ; USB1 : Multilink Universal FX Rev B (PEME049BB)
      Connecting to target.
      P&E Interface detected - Flash Version 9.41

      Can not enter background mode.





      WARNING - NO RESET SCRIPT FILE HAS BEEN CONFIGURED TO RUN!!!

      TO MODIFY THE RESET SCRIPT SETTINGS, USE THE FOLLOWING MENU OPTION:

      CONFIGURATION -> AUTOMATED SCRIPT OPTIONS



      Device is NXP_K2x_K20DX128M5.

      Mode is In-Circuit Debug.

      'Kinetis' is a registered trademark of Freescale.

      (C)opyright 2012, P&E Microcomputer Systems, Inc. (www.pemicro.com)
      API version is 101

      P&E Interface detected - Flash Version 9.41

      Can not enter background mode.



      Unable to initialize PEDebug.

      PE-ERROR: Failed to Initialize Target
      Server 1 running on 127.0.0.1:7224
      Server 2 running on 127.0.0.1:7226
      Server 3 running on 127.0.0.1:7228
      Server 4 running on 127.0.0.1:7230
      Server 5 running on 127.0.0.1:7232
      Server 6 running on 127.0.0.1:7234
      All Servers Running
      Connection from "127.0.0.1" via 127.0.0.1
      PE-ERROR: Target is not connected
      Disconnected from "127.0.0.1" via 127.0.0.1

  • Greetings,

    The GDB server is able to see your multilink. The main issue you are having is between the multilink and the chip/board. Hence the "Can not enter background mode".

    A few things to try:

    1. Do you know if the chip is permanently secured? If the chip has been programmed in the past, it could be that the previous user secured the chip making it impossible for you to enter debug mode on this chip. This can easily happen if the user wrote data between 0x400-0x410. In this case, replace the chip.

    2. If you have an oscilloscope, you should start probing the RESET (pin 10), TDO (pin 6), TDI (pin 8), and TCK (pin 4) lines to see if you have signal toggling. Also check TVCC to see if the voltage is staying at a steady 3.3V or 5V depending on the requirements. If TVCC is not connected, then that would definitely cause a problem. If you have no scope, get a voltmeter, disconnect the multilink, exit from KDS, and try measuring the voltages of TVCC and RESET. Both should be the same and high at either 3.3V or 5V.


    Takao Yamada

  • 1)  I don't know if this happened

    2) I have an oscilloscope and will report back to you.

  • Voltmeter:
    p1 : +3.30V (the board is designed for 3.3V)
    P10 : +3.28V

    Oscilloscope (pegdbserver, SWD mode -- does not enter background mode):
    P2 (SWD_DIO) : toggles
    P4 (SWD_CLK) : toggles (1 MHz edges)
    P6 (NC) : no activity
    P8 (NC) : no activity
    P10 (RESET) : high, no activity

    Oscilloscope (pegdbserver, JTAG mode):
    P2 (TMS) : toggles
    P4 (TCK) : toggles
    P6 (TDO) : floating around 0.7V, no activity
    P8 (TDI) : high

    Note: Changing the "-speed" option from "5" to "1" or "500" did not change the edge rate for SWD_CLK.

    ===========================================================================
    The attached was the single "good" session I got -- it still failed to load the micro controller.
    There were no complaints about not being able to enter "background" mode and the gdb session got far enough for me to type "load" and see the code sections before the GBD server failed.
    ===========================================================================

    P&E GDB Server for Arm(R) devices, Version 5.79.00.00
    Copyright 2014, P&E Microcomputer Systems Inc, All rights reserved

    Loading library /opt/Freescale/KDS_v3/eclipse/plugins/com.pemicro.debug.gdbjtag.pne_2.3.6.201602211227/lin/gdi/unit_ngs_arm_internal.so ... Done.

    Command line arguments: -startserver -device=NXP_K2x_K20DX128M5 -speed=1 -showflashstatus -usejtag
    Device selected is NXP_K2x_K20DX128M5
    HW Auto-Selected : Interface=USBMULTILINK Port=PEME049BB ; USB1 : Multilink Universal FX Rev B (PEME049BB)
    Connecting to target.
    P&E Interface detected - Flash Version 9.41



    WARNING - NO RESET SCRIPT FILE HAS BEEN CONFIGURED TO RUN!!!

    TO MODIFY THE RESET SCRIPT SETTINGS, USE THE FOLLOWING MENU OPTION:

    CONFIGURATION -> AUTOMATED SCRIPT OPTIONS



    Device is NXP_K2x_K20DX128M5.

    Mode is In-Circuit Debug.

    'Kinetis' is a registered trademark of Freescale.

    (C)opyright 2012, P&E Microcomputer Systems, Inc. (www.pemicro.com)
    API version is 101

    P&E Interface detected - Flash Version 9.41



    WARNING - NO RESET SCRIPT FILE HAS BEEN CONFIGURED TO RUN!!!

    TO MODIFY THE RESET SCRIPT SETTINGS, USE THE FOLLOWING MENU OPTION:

    CONFIGURATION -> AUTOMATED SCRIPT OPTIONS



    Device is NXP_K2x_K20DX128M5.

    Mode is In-Circuit Debug.

    'Kinetis' is a registered trademark of Freescale.

    (C)opyright 2012, P&E Microcomputer Systems, Inc. (www.pemicro.com)
    API version is 101

    Server 1 running on 127.0.0.1:7224
    Server 2 running on 127.0.0.1:7226
    Server 3 running on 127.0.0.1:7228
    Server 4 running on 127.0.0.1:7230
    Server 5 running on 127.0.0.1:7232
    Server 6 running on 127.0.0.1:7234
    All Servers Running
    Connection from "127.0.0.1" via 127.0.0.1
    Disconnected from "127.0.0.1" via 127.0.0.1

  • Greetings,

    My first worry is the RESET line. What you should see is:

    1. Reset is driven low by the multilink
    2. Toggling on TCK, TDI and TDO (or SWD_DIO and SWD_CLK) to enable debug mode.
    3. Reset is released by multilink and stays high. Enters debug successfully.
    4. More toggling on TCK, TDI and TDO (or SWD_DIO and SWD_CLK) as debug starts.

    What do you have on the reset line that may interfere with communication. Do you have a reset driver?


    Takao Yamada

  • I tried over a dozen times to confirm what I'd seen on the lack of activity on the RESET signal, however the pegdbserver is always trying to reprogram and it never succeeded.  You can imagine how frustrating this is.

    The board has a TPS3103K33DBVT for a reset controller. Its !RESET pin is connected directly to the MCU, the 10-pin debug header, and through a 33 Ohm resistor to a 0.1" pin header (this is where I've probed the reset signal since it's a lot easier than trying to hold the oscilloscope probe on a tiny solder pin).

    There's a 12 kOhm pull-up resistor on this reset line to the processor and there's a 33 Ohm resistor between the reset controller and the common wire to the 10-pin debug header and the resistor at the 0.1" header.

    I'm wondering how the reset wiring could be causing the USB dongle to need to reprogram so often.

  • Greetings,

    Unless you can get the reset line to go low then high you can ignore what results you see in the GDB server because it is not going to be successful. The real question is why is the multilink not able to pull the reset signal low. I think maybe the resistors are the problem. Usually my suggestion to customers are 10K pull up and no resistors in series. So the 33 ohm resistors you have mentioned may be there for current-limiting protection but also not allowing the multilink to pull the signal low.


    Takao Yamada

  • I went through the circuit again and probed the reset signal again.  This is what I found:

    The reset circuit consists of:
    1) a trace connecting the MCU reset input, one end of a 12k pull-up resistor, the !reset output of a TPS3103K33DBVT, and a test pad;
    2) a connection from this trace through a 33 Ohm resistor to pin 10 of the 10-pin debug connector
    3) a connectiono from pin 10 through a 33 Ohm resistor to an external reset on a 0.1" pin header

    The TPS3103 has an active low, open-drain output.

    If the reset signal is pulled low at the 10-pin debug connector, there will be a 3.3V/(12k+33Ohm) = 0.274 mA current through the 12k pull-up resistor and the 33 Ohm in-line resistor. This corresponds to a 9 mV drop across the 33 Ohm resistor.

    I doesn't seem reasonable for this 9 mV drop to prevent the reset signal from getting to the MCU reset input.

    I tested the cable to see if it could be the problem and I got good connections at both ends of pin 10.

    Finally, at the 10-pin connector on the USB dongle, I connected a 3.3V source between pins 1 and 5 and a 10k resistor between pins 1 and 10. This should mimic the load the reset pin should experience as per your previous suggestion. I then connected my oscilloscope between pins 5 (ground) and 10 (the reset signal). I powered the 3.3V source and then connected the USB dongle and I also applied power in the reverse direction. I also ran the pegdbserver program.

    I SAW NO ACTIVITY ON THE RESET SIGNAL!!!

    I think the dongle is broken. As far as I can tell it isn't generating a reset signal.

  • Greetings,

    Are you located in the USA? If so, I can get you an RMA ticket and have you send the unit to us for evaluation. We will test it out and find out if it needs repair or it needs to be replaced.

    If you are outside of the USA, the cost and time to ship both ways and paying for repair/replacement will be more than simply purchasing a new unit.

    Let me know how you wish to proceed. If possible, you could send a board with your multilink if you wish for us to test against your board and confirm the problem on our end. It would also be ideal if you had a P&E order or invoice number. If you purchased from our distributors, then you will need to find their warranty information if you qualify.


    Takao Yamada

    • I'm in the USA and would like to do the RMA.

      I can't send the board to you, but I do know that the board was programmed about 8 months ago with this dongle.

      I didn't purchase the dongle, my client did, but it came in a FreeScale box and the warrantee inside the box also says FreeScale.

      Please advise on how I should proceed.

  • Greetings,

    Look for the email about how to send the RMA to us. Cost currently is to be determined. If you believe this is under warranty, you need to contact Freescale/NXP about executing on that warranty. You have to purchase directly through us if you wish to have our warranty.

    Warranty is usually one year for manufacturing defects. If you believe your unit is outside of the warranty, then send us the unit and we can look into repair and replacement costs.


    Takao Yamada

Add comment


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







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