Possible way to cause JLink to hang temporarily with Kinetis K60N512

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

  • Possible way to cause JLink to hang temporarily with Kinetis K60N512

    I stumbled upon a sequence of events which seems to hang the JLink Pro (it becomes unresponsive to GDB Server or JLink Commander) requiring me to unplug it's USB connection (and therefore power) and replug it back in, or wait approximately 30 seconds after which the JLink Pro self resets and is back up and communicating. Once in a while the JLink doesn't seem to be able to auto recover.

    The issue seems to be related to the command: monitor speed adaptive

    This issue doesn't seem to occur if I change the command to: monitor speed auto or monitor speed


    This isn't getting in the way of any work as using the "monitor speed auto" works just fine.



    The setup:

    Freescale K60N512 tower:
    JLink Pro version 1.1
    GDB Sever 4.32 running on Windows XP
    arm-eabi-gdb 4.3.2 running on Ubuntu Linux
    simple "hello world" application: hello_world

    GDB command file jlink_rom_k60.gdb containing:

    ######## File Begin ########

    target remote 10.211.55.3:2331

    monitor reset
    monitor sleep 1000

    monitor flash device MK60N512VMD100
    monitor flash download 1
    monitor flash breakpoints 1
    monitor endian little
    monitor speed adaptive
    load
    ######## FILE END ########


    The procedure to cause the issue:

    arm-eabi-gdb --command=jlink_rom_k60.gdb hello_world

    After which the center LED on the JLink turns off.

    After which the outputs:

    The GDB Output:

    ######## GDB Output Begin ########
    richard@ubuntu:~/workspace/Kinetis TWR-K60N512 - hello_world/Debug$ arm-eabi-gdb --command=/opt/ecos/jlink_rom_k60.gdb hello_world
    GNU gdb (eCosCentric GNU tools 4.3.2-sw) 6.8.50.20080706
    Copyright (C) 2008 Free Software Foundation, Inc.
    License GPLv3+: GNU GPL version 3 or later <gnu.org/licenses/gpl.html>
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law. Type "show copying"
    and "show warranty" for details.
    This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-eabi".
    For bug reporting instructions, please see:
    <bugs.ecos.sourceware.org/>...
    0x00000000 in __vector_table ()
    Resetting target
    Sleep 1000ms
    Select flash device: MK60N512VMD100
    Flash download enabled
    Flash breakpoints enabled
    Target endianess set to "little endian"
    Select adaptive clocking instead of fixed JTAG speed
    Loading section .text, size 0x1c2c lma 0x0
    /opt/ecos/jlink_rom_k60.gdb:11: Error in sourced command file:
    Remote connection closed
    (gdb)
    ######## GDB Output End ########




    The GDB Server Output:

    ######## GDB Server Output Begin ########

    SEGGER J-Link GDB Server V4.32

    JLinkARM.dll V4.32 (DLL compiled Jul 29 2011 18:37:55)

    Listening on TCP/IP port 2331

    J-Link connected
    Firmware: J-Link ARM-Pro V1.x compiled Jul 26 2011 17:23:23
    Hardware: V1.10
    S/N: 171100119
    Feature(s): RDI, FlashBP, FlashDL, JFlash, GDB

    J-Link found 1 JTAG device, Total IRLen = 4
    JTAG ID: 0x4BA00477 (Cortex-M4)

    Connected to 10.211.55.4
    Reading all registers
    Read 4 bytes @ address 0x00000000 (Data = 0x20010000)
    Resetting target
    Sleep 1000ms
    Select flash device: MK60N512VMD100
    Flash download enabled
    Flash breakpoints enabled
    Target endianess set to "little endian"
    Select adaptive clocking instead of fixed JTAG speed
    Downloading 7212 bytes @ address 0x00000000WARNING: CPU core not found.
    ERROR: JTAG Timeout during adaptive clocking: RTCK did not respond.
    ERROR: Wrong AHB ID (15:3). Expected 0x04770001 (Mask 0x0FFFFF0F), Found 0x00000000
    Connection to debugger closed !
    ######## GDB Server Output End ########


    The JLink Commander Output:

    ######## JLink Commander Output Begin ########

    SEGGER J-Link Commander V4.32 ('?' for help)
    Compiled Jul 29 2011 18:38:14

    WARNING: Out of sync , resynchronising...


    WARNING: Out of sync , resynchronising...


    WARNING: Out of sync , resynchronising...

    Communication timed out: Requested 2 bytes, received 0 bytes !
    EMU_GetFirmwareString: Insufficient data read when trying to read the string length.
    J-Link>

    ######## JLink Commander Output End ########

    After unplugging the JLink Pro or usually waiting ~30 seconds for the JLink to reset, the JLink is back up and communicating and everything works again.

    If the JLink can't auto recover here is the GDB Server log and see attached image at time 11.08.04 AM:


    After the 30 second period, the center LED on the JLink turns back on, however neither the GDB Server nor JLINK Command can communicate with the JLink.

    ######## GDB Server Log Begin ########

    SEGGER J-Link GDB Server V4.32

    JLinkARM.dll V4.32 (DLL compiled Jul 29 2011 18:37:55)

    Listening on TCP/IP port 2331
    WARNING: Out of sync , resynchronising...

    WARNING: Out of sync , resynchronising...

    WARNING: Out of sync , resynchronising...

    ERROR: Can not connect to J-Link.
    ######## GDB Server Log End ########

    ######## JLink Commander Log Begin ########

    SEGGER J-Link Commander V4.32 ('?' for help)
    Compiled Jul 29 2011 18:38:14

    WARNING: Out of sync , resynchronising...


    WARNING: Out of sync , resynchronising...


    WARNING: Out of sync , resynchronising...

    Communication timed out: Requested 2 bytes, received 0 bytes !
    EMU_GetFirmwareString: Insufficient data read when trying to read the string length.
    J-Link>

    ######## JLink Commander Log End ########

    At this point, the only way to reestablish communciations is to unplug the USB connection to the JLink Pro and re-plug it back in.
    Images
    • Screen shot 2011-08-08 at 10.46.03 AM.png

      16.69 kB, 565×161, viewed 847 times
    • Screen shot 2011-08-08 at 11.08.04 AM.png

      31.86 kB, 550×403, viewed 992 times

    The post was edited 1 time, last by morrisrx ().

  • Hi,

    We will have a look into the "hanging" problem you describe, since this should not happen.
    Thanks for the detailed description how to reproduce the problem.
    Nevertheless, adaptive clocking is not supported for Cortex targets, so this speed setting should not be used.


    Best regards
    Alex
    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.