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.

    • 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).
    • 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.