[SOLVED] How to adjust reset sequence in J-Link (Low level JTAG scan chain configuration) (i.MX6Q)

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

  • [SOLVED] How to adjust reset sequence in J-Link (Low level JTAG scan chain configuration) (i.MX6Q)

    Dear Community,

    I need to tune the default reset sequence (executed thereafter with 'mo reset').


    The problem:
    -------------------
    Stop SoC (i.MX6Q) just after powering it up (in the early SRAM - 0x908000 address
    in this case). This is necessary for debugging early bootloader code (U-Boot SPL
    to be precise).

    I've tried to pass adjusted SetResetTime (it provides only ms resolution) and
    SetResetType=0 to ./JLinkGDBServerExe.

    Unfortunately, the result is not acceptable - I still see SPL welcome prompt
    "U-Boot SPL 2019.10-00343-" after "mo reset".
    This is too late for early debugging.

    It seems like I do need to configure TAP before ARM debug interface is visible
    and accessible in the usual way.

    With other tool I was able to specify following "reset" sequence [*]:
    Assert RESET -> wait 100us -> assert TRST -> wait 100us -> deasert TRST -> deasert RESET -> wait 20ms -> Set TCK and TMS to HIGH -> wait 1ms

    Please correct me - but it seems to me that I do need to re-implement ResetTarget()
    function in *.JLinkScript file and use JTAG_* global DLL variables (e.g. JTAG_TRSDPin)
    from [1] 7.13.3 ?

    One problem is that JLINK_SYS_Sleep() (7.13.2.50) has only ms resolution. Is there

    a function with us resolution?



    Do you maybe have an example code for [*] reset adjustments?

    Thanks in advance for help.

    Link:
    [1] - segger.com/downloads/jlink/UM08001
  • Interesting.

    So you saying, If I understand it right, it's coming out of reset but then is to quick for you to halt it ?

    Have you tried: connect to to the core, halt; set hardware bp at your wanted reset stop (0x908000 seems), reset the target & run. Should hit it..

    [ Note: I provide U-boot & Linux kernel debug setup & consulting based on Segger J-Link;
    I focus on NXP iMXx, in particular with heterogenous cores - with real-time/M core and one or more A cores for Linux.

    Please shoot me
    a message if you interested in my consulting services: eager to help with all your U-Boot & Linux setup issues, as well as development. ]
  • Hi,

    Thank you for your response.
    My approach (I think that it is what your suggested above):

    Power cycle the board

    Go to the U-Boot prompt >
    Start GDB server: ./JLinkGDBServerExe -select USB -device MCIMX6Q7 -endian little -if JTAG -speed auto -noir -noLocalhostOnly


    arm-linux-gnueabihf-gdb


    (gdb) target remote localhost:2331
    (gdb) hb *0x908000
    Hardware assisted breakpoint 1 at 0x908000
    (gdb) i b
    Num Type Disp Enb Address What
    1 hw breakpoint keep y 0x00908000
    (gdb) mo reset
    Resetting target

    (gdb) i r pc
    pc 0x4ff8d41e 0x4ff8d41e


    (The 0x4fxxyyyy is a range of SDRAM of i.MX6Q, which is not corresponding to
    OCRAM - 0x908xxx)


    And on the console I do see following output:
    U-Boot SPL 2019.10-00343-




    Of course I can load u-boot-spl manually via GDB:
    (gdb) load /srv/tftp/u-boot-spl


    Start address 0x908000, load size 64945
    Transfer rate: 73 KB/sec, 7216 bytes/write.
    (gdb) i r pc
    pc 0x908000 0x908000


    (gdb) c
    Continuing.


    Breakpoint 1, 0x00908000 in ?? ()
    (gdb) i b




    However, I would like to know how early I can stop the i.MX6Q when I do generate
    the reset (with 'mo reset'). This may be helpful when debugging the SoC state after
    going out of ROM bootloader.


    To be more specific - I would like with the J-Link PRO to control the TRST and !RESET
    with micro seconds (us) resolution and have the same signals generated as described in the
    first message in this thread.
  • Hey Lukma,

    lukma wrote:

    (gdb) target remote localhost:2331
    (gdb) hb *0x908000
    ...........

    Yes..

    lukma wrote:

    However, I would like to know how early I can stop the i.MX6Q when I do generate
    the reset (with 'mo reset'). This may be helpful when debugging the SoC state after
    going out of ROM bootloader.
    You should set it up from the first U-boot instruction, i.e. after ROM code loaded it and starts to execute it.
    I don't think you want to debug the SoC ROM code.

    Also keeping in mind, as you were asking on another thread, U-boot relocates itself when it starts (so there are 2 loads).
  • lukma wrote:

    Hi,

    Thank you for your response.
    My approach (I think that it is what your suggested above):

    Lukma,

    If you / your Co is willing / in -need, I can deliver a working debug setup on U-boot and Linux kernel, for your SoC/board, if we agree contractually (need some money for food , or to buy more J-Links ;) )

    I deliver in a virtual machine (prefer VBox), and done this before. Setup will be based on Segger J-Link + GDBServer; hardware wise any J-Link above EDU, I would say, and, I strongly prefer USB iface than IP.
    (As you noticed, multi-core debug with Segger does appear to work with USB, and I don't think I want to debug the remote TCP server issues).
  • Hi,

    Please don't get me wrong, but I think that we are going off topic a bit here.

    The original question was about the possibility to emulate/generate with Segger setup the TRST and !RESET signals with micro seconds resolution.
  • lukma wrote:



    The original question was about the possibility to emulate/generate with Segger setup the TRST and !RESET signals with micro seconds resolution.

    It is true, apologies :)

    I still do not understand why you want /need it. For what you wrote :

    ... SoC state after going out of ROM bootloader.


    Unfortunately, the result is not acceptable - I still see SPL welcome prompt
    "U-Boot SPL 2019.10-00343-" after "mo reset".
    This is too late for early debugging.
    ...

    Seems trying to catch U-boot executing ... SoC state after going out of ROM, etc.. Overall, it may stand out you probably do not need to do what your thread's topic is asking, based on the rest what you wrote here, if it represents what you trying to achieve.

    However, sorry I intervened, was too keen when saw you tinkering with U-boot & Linux.

    Good luck
  • My point was as follows:

    - Power cycle the board
    - Stop it in U-Boot prompt
    - Attach with GDB (target remote localhost:2331)
    - execute (gdb) mo reset

    Then I've checked:

    What is the output of the serial console ?
    What is the output of (gdb) i r pc ?

    In my case it was to late (when compared to other tool which I do use) as stated in the first message.
    That is what I had from the J-Link out of the box with default settings.


    Then I've pointed out that with some other tool I can set/clear TRST and !RESET with us resolution and the board
    stops earlier (in ROM). This is my reference point.

    v01d wrote:

    However, sorry I intervened, was too keen when saw you tinkering with U-boot & Linux.

    I'm more than happy that you try to help people. This pays off. Always.
  • To answer the original question:

    lukma wrote:

    The original question was about the possibility to emulate/generate with Segger setup the TRST and !RESET signals with micro seconds resolution.
    This is not possible right now.
    It may be in in a future version but not right now.
    For what do you need a [us] solution here?