Posts by mastupristi

  • Using SWO for Character Output in Production with J-Link Commander (No Debug)

    I’m working in a production setup (not a development/debug session), where each board must be prepared before its main flash image is programmed. Our process is (simulated with EVK):

    1. Connect to the MIMXRT1021-EVK via a Segger J-Link (SWD + SWO).
    2. Use J-Link Commander (JLink.exe / JLinkCommander) to load our custom firmware into RAM.
    3. Start execution immediately with the g command.

    In this context I do not attach a debugger or IDE—everything runs “headless” via J-Link Commander scripts. What I’d like to do is have the running firmware emit simple status or log messages over the SWO pin (ITM port 0 → TPIU), so that our production test station can capture and display these messages without stopping the CPU.
    My questions are:

    1. Is it possible to enable and view SWO output purely from J-Link Commander, without starting a full debug session?
    2. If so, what is the exact sequence of J-Link Commander commands to

      • configure the SWO pin protocol and baud rate,
      • enable the ITM stimulus port,
      • and capture the output in the console?

    I’m already comfortable initializing SWO in firmware (DEMCR, TPIU, ITM regs, etc.), but I need to know the proper J-Link Commander commands to turn on the trace port and route its output to the stdout of J-Link Commander.
    Any example scripts or pointers to the relevant manual sections would be greatly appreciated!
    Thank you in advance,

    Max

  • Preserving a Sub-Range of QSPI-NOR Flash with J-Link Commander on NXP RT1xxx

    Hello,

    I read this: https://kb.segger.com/ConfigTargetSe…illegal_regions

    and I tried this script:

    Template_ExcludeIllegalRegions.JLinkScript

    Then I try to attach to MIMXRT1021-EVK:

    /opt/SEGGER/JLink/JLinkExe -if SWD -speed auto -device MIMXRT1021xxx5A -autoconnect 1 -JLinkScriptFile Template_ExcludeIllegalRegions.JLinkScript

    I get this:


    I want to override the area 0x60000000-0x600001FF , I need to do this.

    I don't even know how memory regions are defined now (how can I print them?).

    How can I solve it?

    best regards
    Max

  • Preserving a Sub-Range of QSPI-NOR Flash with J-Link Commander on NXP RT1xxx

    Hello everyone,
    I’m using Segger J-Link v8.30 and an NXP RT1xxx MCU that boots from external QSPI-NOR flash mapped, for example, at 0x3000 0000. Although the NOR flash supports 4 KiB sector erases at the hardware level, J-Link Commander (and the GDB Server) currently always performs erases in 64 KiB blocks. When I write the FW into the flash I need to preserve 512 bytes at 0x3000 0400–0x3000 05FF, which contain data that must survive every download.
    Key details:

    • Hardware sector erase size: 4 KiB
    • J-Link software erase granularity: 64 KiB
    • Regions to rewrite:

      • 0x3000 0000–0x3000 03FF
      • 0x3000 0600–0x300x xxxx
    • Region to preserve: 0x3000 0400–0x3000 05FF

    In development and debugging I use the GDB Server, but for simple production programming I rely on J-Link Commander.

    How can I achieve this with J-Link software?

    Thank you!

  • RT117x CM4: problem when FW is bigger than 57344 (0xe000) bytes

    Hi,

    we have a bit of a problem with FWs larger than 57344 bytes (0xe000 in hexadecimal), that run XIP from flash, and we connect to CM4.
    We were also able to reproduce the problem with an example SDK (which I attach) on MCUXpresso IDE v11.10.0 [Build 3148] and running on EVKB, and JLink (tested 7.98h and .7.96o)


    In fact, the FW resides in flash at address 0x08002000 (but I have also tried having it reside at 0x08012000, with the same results)
    The flash is correctly written in all cases. If the FW is smaller the JLink debugging session starts without problems. While with larger FWs it does not, and the Program-counter we find it at an address of 0x2020xxxx, where the JLink RAMCode should reside
    but we didn't map anything there.


    To implement the FW “bloat” I used an array, not used by anyone in the code (so as not to alter it), but present in the executable thanks to a special KEEP() directive on the linking options:

    If the id 39676 threshold is exceeded, the flash image exceeds 57344 bytes and what happens is that it doesn't get to the main because the PC stays somewhere in 0x2020xxxx


    An interesting coincidence is that the FW, as mentioned resides at 0x08002000, and so exceeding the size 0xe000 means exceeding 0x08010000, an oddly round number. For these reasons, we tried to place at 0x08012000 but did not notice any change.


    can you also try it and help us figure out where we are going wrong?


    regards

    Max

  • Very inefficient flash writing process (on RT1170)

    Hello,
    I traced the process of writing a FW in flash using a logic state analyzer. I was able to observe some very questionable behaviors.


    The file is quite large, and even its decoding contains more than 3,000 commands. However, there are some peculiarities that I would like to discuss with you


    Reads take place byte by byte
    I was able to observe that the memory reads, in the initial comparison and in the final verification are done using the 0x6B command, but one byte at a time. In this way, reading 1kB takes 40960 clock cycles. Whereas on the other hand if I read the same kB in one transaction it would take 2086 clock cycles!!! That's a 95% reduction in time!!!!
    Why do you read one byte at a time?


    QE bit is written and rewritten many times (for no reason at all)
    In the track I took the QE bit is written and rewritten a total of 79 times. Very often between two consecutive writes (one 0 and the other 1 or vice versa) there are no other operations, making the write completely useless. Also Even if QE bit is 1 the "normal" commands still work, so there is no need to rewrite QE to 0 for the Page Program or Block Erase commands.


    At the end QE bit remains at 0
    The rom bootloader requires the QE bit to be 1 in the flash. But the last write done leaves the QE bit at 0, so after a flash write the FW will still not be executable until we rewrite the QE bit to 1 using another FW (residing in RAM)


    The value of dummy cycles is never read
    The memory I'm using right now is an Infineon S25FL064L (ID 01 60 17). It has the setting of the number of dummy cycles in the config3 register. The command to read that data is 0x33. This command is never sent to the flash, so how does the FW know how many dummy cycles to add to the readings?


    The number of bytes of the address is not read.
    The flash can use 3 or 4 bytes of address. setting is contained in the Config2 register, which can be read with the 0x15 command. But that command is never sent to the flash.

    64kB blocks are deleted
    Deletions are made by 64kB blocks. Wouldn't it be more efficient to do it by 4kB sectors (supported by flashes with the 0x20 command)? This would have a finer grain at the cost of a little more time to erase, which is possible to recover by doing better reads


    I know that a FW is injected inside the micro that is used to perform the actual operations (FlaxSPI programming, reads, writes, etc.). Is it possible to get the source code of such FW?

    Let me know if you want the trace (in sigrok format) and how you can share it


    best regards

    Max

  • write in the flash in twice

    hi,
    I use RT1176 and i have to write flash (mapped to 0x30000000)
    The FW is divided into two parts,

    • a first part called the boot header exactly 8K in size
    • a second part which is the actual application and starts at offset 0x2000.

    For each of the two parts I have an elf file.


    How do I write both parts into the flash using a script?

    I tried the following script:

    Code
    device MIMXRT1176xxxA_M7
if SWD
speed auto
connect
sleep 1
loadfile "FW/image/Ama_BootHdr.elf"
sleep 1
loadfile "FW/image/Ama.elf"
exit


    But I get a timeout error when trying to write the second part:

    in particular I notice that the affected ranges for the boot header is 64KB which corresponds to the largest erasable sector of my flash. In addition, I have a verification error.

    I tried swapping the two files:

    Code
    device MIMXRT1176xxxA_M7
if SWD
speed auto
connect
sleep 1
loadfile "FW/image/Ama.elf"
sleep 1
loadfile "FW/image/Ama_BootHdr.elf"
exit


    the behavior changes, I no longer have timeouts:


    for both parts I have the address 0x30000000, which is incorrect for the application, and the affected range is 262144 for both. They also both fail verification.


    so how should the script be for me to write the two parts, verifying both?

    best regards
    Max

  • [SOLVED] unknown entry point in jlink command file

    I work with RT1051 and I have a project contained and executed in RAM.
    I wrote a command file to automate loading and execution:

    Every version I make <ENTRYPOINT> can change, forcing me to introspect the produced binary.

    To automate this aspect as well, how could I do it?

    For example, is it possible to pass parameters from JLink command line to CommandScript? Or is it possible to declare variables inside the script that I would populate by reading the content of a specific memory location (the address of the ResetISR inside the vectors)? Or are there other methods I haven't considered like JlinkScripts?


    best regards
    Max

  • [SOLVED] source code for i.MXRT1050_QSPI flashloader

    Is the source code of i.MXRT1050_QSPI flashloader available?
    I would need to see how the pins, clocks, and MPU are configured.
    I hope and believe there is nothing to keep hidden since the hidden part is distributed as a pre-compiled library (SEGGER_OFL_Lib_CortexM_LE.a). I'm just talking about startup code and the various functions to populate as explained in the wiki page https://wiki.segger.com/Open_Flashloader

    best regards
    Max

  • [ABANDONED] cannot write Flash on RT1061

    I'm having trouble with an RT1061. I am attaching the log file.

    The J-Link works since I can write and debug FW in RAM. Flash works since my FW in ram can read and write flash correctly. Also J-Link can read the content of the flash. The power supply is stable and the clock is working.
    The error is:

    What are the reasons why it can fail like this?

  • [SOLVED] Debug i.MX RT1051 using J-Link when FW is loaded from QSPI to ITCM

    I am able to build a firmware that resides in QSPI and that is loaded into ITCM from the ROM bootloader at startup.

    What happens, for example on the EVKB, is that J-Link correctly writes the FW in QSPI flash then sets the program counter at the entry point.
    Unfortunately, in this way, what is being executed is not the firmware just written, but the one that was running before writing, because the RAM is not touched by J-Link. It should be the ROM bootloader that populates the RAM.

    I would like to have J-Link, once the FW is written in QSPI, trigger the ROM bootloader. I'm trying to write a script without success.
    How can I do that?

    best regards
    Max

  • [SOLVED] JTAG connection with i.MX RT1050 EVKB

    We have a custom board project equipped with two i.MX RT1051.
    We would like to use the JTAG connection, instead of the SWD, in order to link the two MCUs, as shown here
    https://en.wikipedia.org/wiki/JTAG#Dais…G_(IEEE_1149.1)
    [Blocked Image: https://upload.wikimedia.org/wikipedia/commons/c/c9/Jtag_chain.svg]
    so we can only use one program/debug connector.
    The preliminary step for us is to make the JTAG connection work on EVKB (taking care to pull up the JTAG_MOD signal). However, the connection is not established.

    We wonder where we're wrong. Is there any special command or parameter for J-Link? We wonder if the RT105x supports JTAG for programming and debugging or just boundary scan.
    best regards
    Max

  • [SOLVED] writing i.MX RT1051 eFuses through J-Link

    maybe I didn't explain myself well: I am perfectly aware of the manual and of the existence of the described procedure.
    I wondered if J-Link would offer any shortcuts to do this, given the criticality: they are one time programmable, and an error could compromise the chip irreversibly.
    Moreover, the programming of the QSPI also involves an algorithm of several steps. However, this is provided by J-Link as functionality.

    In any case, I understand that Segger has not addressed with the issue leaving it entirely to the users, right?

    best regards
    Max