[SOLVED] J-Link running as multiple single-steps when used with ARM Cortex-A9 from IAR Embedded Workbench

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

  • [SOLVED] J-Link running as multiple single-steps when used with ARM Cortex-A9 from IAR Embedded Workbench

    Hi,

    I'm wondering if you can provide some clues as to what's happening when I run firmware on a SoC containing an ARM Cortex-A9 from a recent version of IAR embedded workbench (v8.40.1.2xxxx).

    The symptom is that everything connects and downloads OK, but when the run button is used, the firmware runs very, very slowly. Looking at the j-link logs this appears to be because the application is running as a series of single-steps (note that it is not being paused and re-started, it should be just free-running). The following is an excerpt from the log when running in this way:

    ...
    T2FD4 013:169 JLINK_ReadRegs(NumRegs = 1, Indexes: 34) -- SPSR_UND=0x8018781 returns 0x00 (0000ms, 6909ms total)
    T2FD4 013:169 JLINK_ReadMemU32(0x60101528, 0x0001 Items, ...) -- CPU_ReadMem(4 bytes @ 0x60101528) - Data: 03 00 00 EF returns 1 (0002ms, 6911ms total)
    T2FD4 013:171 JLINK_Step() -- CPU_ReadMem(64 bytes @ 0x60000000) -- Updating DA cache (64 bytes @ 0x60000000) -- Read from DA cache (4 bytes @ 0x60000008) -- Read from DA cache (4 bytes @ 0x60000028) -- Simulated returns 0x00 (0003ms, 6914ms total)
    T2FD4 013:174 JLINK_WaitDCCRead(TimeOut = 0) returns 0x00 (0001ms, 6915ms total)
    T2FD4 013:177 JLINK_IsHalted() returns TRUE (0000ms, 6915ms total)
    T2FD4 013:177 JLINK_WaitDCCRead(TimeOut = 0) returns 0x00 (0000ms, 6915ms total)
    T2FD4 013:177 JLINK_WaitDCCRead(TimeOut = 0) returns 0x00 (0001ms, 6916ms total)
    T2FD4 013:178 JLINK_ReadRegs(NumRegs = 1, Indexes: 9) -- R15 (PC)=0x60002418 returns 0x00 (0000ms, 6916ms total)
    T2FD4 013:178 JLINK_WriteVectorCatch(0x00000004) >0x78 JTAG> >0x40 JTAG> >0x30 JTAG> >0x30 JTAG> >0x30 JTAG> >0x40 JTAG> >0x30 JTAG> returns 0x00 (0003ms, 6919ms total)
    T2FD4 013:181 JLINK_Go() -- CPU_WriteMem(4 bytes @ 0x19010140) -- CPU_WriteMem(4 bytes @ 0x19010144) -- CPU_WriteMem(4 bytes @ 0x19010148) -- CPU_WriteMem(4 bytes @ 0x1901014C) -- CPU_WriteMem(4 bytes @ 0x19010150) -- CPU_WriteMem(4 bytes @ 0x19010154) (0008ms, 6927ms total)
    T2FD4 013:189 JLINK_WaitDCCRead(TimeOut = 0) returns 0x00 (0001ms, 6928ms total)
    T2FD4 013:192 JLINK_IsHalted() returns TRUE (0005ms, 6933ms total)
    T2FD4 013:198 JLINK_WaitDCCRead(TimeOut = 0) returns 0x00 (0000ms, 6928ms total)
    ...
    T2FD4 013:218 JLINK_ReadRegs(NumRegs = 1, Indexes: 34) -- SPSR_UND=0x8018781 returns 0x00 (0000ms, 6948ms total)
    T2FD4 013:218 JLINK_ReadMemU32(0x60101528, 0x0001 Items, ...) -- CPU_ReadMem(4 bytes @ 0x60101528) - Data: 03 00 00 EF returns 1 (0002ms, 6950ms total)
    T2FD4 013:220 JLINK_Step() -- CPU_ReadMem(64 bytes @ 0x60000000) -- Updating DA cache (64 bytes @ 0x60000000) -- Read from DA cache (4 bytes @ 0x60000008) -- Read from DA cache (4 bytes @ 0x60000028) -- Simulated returns 0x00 (0003ms, 6953ms total)
    T2FD4 013:223 JLINK_WaitDCCRead(TimeOut = 0) returns 0x00 (0001ms, 6954ms total)
    T2FD4 013:226 JLINK_IsHalted() returns TRUE (0000ms, 6954ms total)
    T2FD4 013:226 JLINK_WaitDCCRead(TimeOut = 0) returns 0x00 (0000ms, 6954ms total)
    T2FD4 013:226 JLINK_WaitDCCRead(TimeOut = 0) returns 0x00 (0001ms, 6955ms total)
    T2FD4 013:227 JLINK_ReadRegs(NumRegs = 1, Indexes: 9) -- R15 (PC)=0x60002418 returns 0x00 (0000ms, 6955ms total)
    T2FD4 013:227 JLINK_WriteVectorCatch(0x00000004) >0x78 JTAG> >0x40 JTAG> >0x30 JTAG> >0x30 JTAG> >0x30 JTAG> >0x40 JTAG> >0x30 JTAG> returns 0x00 (0003ms, 6958ms total)
    T2FD4 013:230 JLINK_Go() -- CPU_WriteMem(4 bytes @ 0x19010140) -- CPU_WriteMem(4 bytes @ 0x19010144) -- CPU_WriteMem(4 bytes @ 0x19010148) -- CPU_WriteMem(4 bytes @ 0x1901014C) -- CPU_WriteMem(4 bytes @ 0x19010150) -- CPU_WriteMem(4 bytes @ 0x19010154) (0008ms, 6966ms total)
    T2FD4 013:238 JLINK_WaitDCCRead(TimeOut = 0) returns 0x00 (0001ms, 6967ms total)
    T2FD4 013:241 JLINK_IsHalted() returns TRUE (0005ms, 6972ms total)
    T2FD4 013:246 JLINK_WaitDCCRead(TimeOut = 0) returns 0x00 (0001ms, 6968ms total)
    ...

    What appears to be happening is that after the JLINK_Go() the JLINK_IsHalted() always returns TRUE and so there are then a number of register/memory location read updates and the JLINK_Go is issued again.

    I have found that by disconnecting from the target and then using IAR's 'Attach to running Target' option that things run much better and continue to do so even when I pause and press run again, so I'm using this as a workaround. I've captured the log from a re-start sequence after a pause once re-attached, and the sequence from JLINK_Go is slightly different:

    T12EC 010:323 JLINK_ReadRegs(NumRegs = 1, Indexes: 34) -- SPSR_UND=0x8008781 returns 0x00 (0000ms, 0168ms total)
    T2A6C 011:037 JLINK_WriteVectorCatch(0x00000000) >0x40 JTAG> >0x40 JTAG> >0x30 JTAG> >0x30 JTAG> >0x30 JTAG> >0x40 JTAG> >0x30 JTAG> returns 0x00 (0002ms, 0170ms total)
    T2A6C 011:039 JLINK_Go() -- CPU_WriteMem(4 bytes @ 0x19010100) -- CPU_WriteMem(4 bytes @ 0x19010140) -- CPU_WriteMem(4 bytes @ 0x19010104) -- CPU_WriteMem(4 bytes @ 0x19010144) -- CPU_WriteMem(4 bytes @ 0x19010148) -- CPU_WriteMem(4 bytes @ 0x1901014C) -- CPU_WriteMem(4 bytes @ 0x19010150) -- CPU_WriteMem(4 bytes @ 0x19010154) (0010ms, 0180ms total)
    T2A6C 011:049 JLINK_WaitDCCRead(TimeOut = 0) returns 0x00 (0001ms, 0181ms total)
    T2A6C 011:052 JLINK_IsHalted() returns FALSE (0000ms, 0181ms total)
    T2A6C 011:052 JLINK_WaitDCCRead(TimeOut = 0) returns 0x00 (0001ms, 0182ms total)
    T2A6C 011:055 JLINK_IsHalted() returns FALSE (0000ms, 0182ms total)

    There appear to be 2 main differences:
    Firstly there is no JLINK_Step() call when running after re-attaching and secondly the address in the JLINK_WriteVectorCatch is different.

    I'm not sure to what extent this is due to how IAR drive the j-link or whether there is some configuration I can use in the j-link setup script so that the desired behaviour happens without having to disconnect and re-connect. I haven't been able to find much information about the JLINK_WriteVectorCatch call either but perhaps this is an internal jlink function call that is not publicly documented ?

    For reference the j-link logs report the following j-link/segger versions :
    Firmware: J-Link V9 compiled May 17 2019 09:50:41
    Hardware: V9.10
    S/N: 59101789
    Feature(s): GDB, JFlash

    Thanks for any help you can provide for this,

    Regards,

    Steve

  • I believe I've now found the problem - the IAR project had "Library low-level interface implementation" set to "Semihosted" which appears to result in an SVC vector catch being added on connection. Setting this to "None" resolves the issue.

    The re-attach worked around this because the debugger was unable to set the vector catch while the target was running so the problem then didn't manifest.

    Regards,

    Steve

  • Hello Steve,
    I am happy that you were able to resolve the issue.

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