[ABANDONED] RT1061 debugging issue (JLink)

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

  • [ABANDONED] RT1061 debugging issue (JLink)

    Hello,

    We are developing an application for NXP RT1061 (custom board) and are experiencing some issues when it comes to debugging.

    MCU: MIMXRT1061CVL5B
    Flash: IS25LP032D
    Debuger: JLink Plus (Firmware: J-Link V11 compiled May 2 2022 08:59:57, Hardware: V11.00)

    A complete log and flash configuration is attached.

    1. The JLink server seems to have problems halting the mcu after reset, when running and debugging from flash, hinting that we have faulty flash settings.
    This causes for example breakpoints in the beginning of main not to trigger. And possibly also other issues as described below.

    Log from JLinkServer:
    Received monitor command: reset
    ResetTarget() start
    Core did not halt on flash image verification. Assuming faulty flash settings.
    Halting target manually.
    ResetTarget() end

    What causes this, do we have the wrong flash configuration?

    2. We have no problem booting from the flash. However once a program is present in the flash the Jlink Debugger is unable to reprogram the flash. Could be related to issue 1 since if we insert a delay in the beginning of main it works. We have some units which we at the moment are unable to recover because of this.

    We suspect that configuring the MPU or something similar to this prevent JLink from uploading its "Ram code" but we have not been able to confirm this. We have however tried to disable the MPU using JLink commander but have not been successful. The FlexRam module has default configuration (128k DTC, 128K ITC, 256K OC).

    Log from JLinkServer:
    Downloading 2964 bytes @ address 0x60025550 - Verified OK
    Downloading 84 bytes @ address 0x600260E4 - Verified OK
    ERROR: Failed to prepare RAMCode using RAM
    Error while determining flash info (Bank @ 0x60000000)
    Writing register (PC = 0x60002308)

    3. Starting a debug session takes a long time.
    The time from when the program has been written to flash/ram and the triggering of the first breakpoint in main is long sometimes more than a minute. This could for some reason be a related to the application size since we do not experience this issue when running nxp's example applications. Our application is around 400k. This happens both if we execute from ram and flash.

    We are using McuXpresso.

    What could be causing this? Anything we can do to improve the debugging experience.

    Thanks
    /Björn
    Files

    • jlink-log.txt

      (2 Byte, downloaded 155 times, last: )

    • flash-config.txt

      (1.38 kB, downloaded 145 times, last: )

  • Hi,

    If you are entitled for support, we recommend to go through the regular support channel, as there is no guarantee to receive any answer from SEGGER employees here in the forum.

    We only guarantee that our flash loaders are able to program the flash in factory default state. If you put it into some XIP, QPI, … mode it does not boot into by factory default, flash programming may fail.
    As you are able to program an application in the first place, the flash loader does what is guaranteed.
    You may write your own flash loader, which handles your setup specifics, at any time.
    wiki.segger.com/Open_Flashloader

    Something similar for reset.
    Our reset sequence is guaranteed to work for a factory fresh device and may also handle some other „common“ boot modes as well.
    However, with nowadays chips which can have dozens of boot modes, it is simply not possible to write THE perfect reset that covers all cases (and for ALL chips J-Link does support) and still stay profitable at the same time.
    You may write your own reset sequence at any time.
    wiki.segger.com/J-Link_script_files

    We can offer you to have a look at your specific case but it will very likely require getting HW and will be subject to NREs.
    If this is of interest, please let me know and I will put you in touch with the right people over here
    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.

  • In the end it turns out that there is a bug in the newer versions of the JLink software, downgrading the to version 7.52b solves issue 1. Our guess is that it is a bug in the JLink GDB Server.
    Issue 2 is a consequence of the jlink not halting the processor giving it time to enable the d-cache.

    Issue number 3 above turns out to be related to McuXpresso, we are not seeing this issue with Ozone.