[SOLVED] STM32F767 :: J-Trace Pro :: No half-sync pattern detected

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

  • [SOLVED] STM32F767 :: J-Trace Pro :: No half-sync pattern detected

    Hello all,

    I get the following error (see screenshot attached) when I enable trace (4 pin) in Keil µVision V5.22 with STM32F767 connected.

    The webserver of the J-Trace Pro shows this:


    Trace status
    Trace clock:0 kHz
    Half-sync detection:0x00000000 (Not O.K. no half-sync pattern detected)
    Last incorrect half-sync sampled:0x00000000


    The trace connector seems to be correct (see 2nd attachment).
    SYS_TRACECLK = PE2
    SYS_TRACED0 = PG13
    SYS_TRACED1 = PE4
    SYS_TRACED2 = PE5
    SYS_TRACED3 = PE6

    What did I do wrong?
    Kind regards

    Marcus
    Images
    • screenshot.png

      46.59 kB, 1,204×329, viewed 621 times
    • trace_connector.png

      25.29 kB, 508×418, viewed 856 times
  • Hello Marcus,

    Thank you for your inquiry.
    The trace clock reads 0 Hz which indicates that a trace clock is not output.
    In Keil trace configuration must be done by the user unfortunately.
    For more information about this please contact Keil.

    To offer our J-Trace customers an easy entry into Trace setups we created multiple example projects for our debug software Ozone which can be used with Keil output as well.
    wiki.segger.com/Tracing_on_ST_STM32F767
    Could you test out that example project and report if trace is working on your board?
    The example projects does no PLL or peripheral init so you should be able to use it on other boards than the Nucleo board from the example as well.
    To configure it to more than 1-bit trace simply edit the JLinkScript from the project.
    How is described here: segger.com/products/debug-prob…hnology/setting-up-trace/

    We also noticed that you have put Zener diodes on the trace lanes in your board design. Depending on the capazitive impact of such diodes they can lead to problems with trace signals at higher trace clock speeds. Generally we suggest to remove all capazitive or inductive loads from the trace lanes to reduce interference with the trace signals.

    Best regards,
    Nino
    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.
  • Dear Nino,

    thanks for your rapid reply.
    I ported your example "ST_STM32F767_8MHz_TraceExample" for Keil µV5.22 which worked fine, Ozone 2.50b is running. I configured the 4-pin tracing within Ozone within Edit > Trace Settings.

    The Webserver of the J-Trace Pro (192.168.1.103/traceconfig.htm) now says:
    Trace clock : 8070 kHz
    Half-sync detection: 0x00000000 (Not O.K. ....)

    Is this correkt - or should I expect half-sync detection to be != 0?

    When I now enable "Trace" in Keil Project options > Debug J-Link..Settings > Trace, then Keil produces a similar error as posted from me before (see attachment).

    I adjusted the Jlink-Script "ST_STM32F767_Modified_Traceconfig.JLinkScript" by setting
    JLINK_TRACE_PortWidth = 4;
    which does not help - the error also happens with PortWidth = 1;

    Regards
    Marcus
    Images
    • error.png

      160.02 kB, 1,604×1,176, viewed 453 times
  • Hello Marcus,

    were you able to get trace running in Ozone?
    You should see valid half synchs when your application is halted. Then the target device will output only half synchs.
    Are you using an eval board for your setup or custom hardware?
    To enable trace in Keil the JLinkScript can't be used.
    The error you see happens when the trace initialization in Keil is false or missing.
    Please understand that we can't offer support regarding trace init in uVision as it is not our software.
    We suggest to contact Keil directly in that regard.

    To avoid the issues you see with Keil we recommend using Ozone with Keils output file. So you debug with Ozone and compile with Keil.

    We also offer our own IDE Embedded Studio which also has a Keil project importer so you can quickly migrate from uVision to Embedded Studio and enjoy full benefits of our debug probes.

    Best regards,
    Nino
    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.
  • Hi Nino,

    I am not sure whether trace is really running in Ozone ...

    When I click View > Instruction Trace or Code Profile the orange Trace LED is on and the output of the webserver is:

    Trace clock: 8080 kHz
    Half-sync detection: 0xE6EEE6EE (Not O.K. no half-sync pattern detected)
    Last incorrect half-sync sampled: 0xE6EEE6EE

    The code runs, but, e.g., the run count within the code profile is not updated (see also pasted console output below).
    I assume, the trace pins may not be correctly configured. As written in my initial post, we have TRACED0 on PG13 and not on PE3.

    Does this have to be reflected in some change in the JLinkScript?

    Thanks and kind regards

    Marcus


    Window.Clear ("Console");
    Debug.SetConnectMode (CM_DOWNLOAD_RESET);
    Debug.Start();
    Project.SetJLinkScript ("./ST_STM32F767_Modified_Traceconfig.JLinkScript");
    Executed J-Link command "ScriptFile=D:/Software/Gamma/ST_STM32F767_8MHz_TraceExample/ST_STM32F767_Modified_Traceconfig.JLinkScript"
    J-Link: Device "STM32F767II" selected.
    J-Link: Found SW-DP with ID 0x5BA02477
    J-Link: Found SW-DP with ID 0x5BA02477
    J-Link: Scanning AP map to find all available APs
    J-Link: AP[1]: Stopped AP scan as end of AP map has been reached
    J-Link: AP[0]: AHB-AP (IDR: 0x74770001)
    J-Link: Iterating through AP map to find AHB-AP to use
    J-Link: AP[0]: Core found
    J-Link: AP[0]: AHB-AP ROM base: 0xE00FD000
    J-Link: CPUID register: 0x411FC270. Implementer code: 0x41 (ARM)
    J-Link: Found Cortex-M7 r1p0, Little endian.
    J-Link: FPUnit: 8 code (BP) slots and 0 literal slots
    J-Link: CoreSight components:
    J-Link: ROMTbl[0] @ E00FD000
    J-Link: ROMTbl[0][0]: E00FE000, CID: B105100D, PID: 000BB4C8 ROM Table
    J-Link: ROMTbl[1] @ E00FE000
    J-Link: ROMTbl[1][0]: E00FF000, CID: B105100D, PID: 000BB4C7 ROM Table
    J-Link: ROMTbl[2] @ E00FF000
    J-Link: ROMTbl[2][0]: E000E000, CID: B105E00D, PID: 000BB00C SCS
    J-Link: ROMTbl[2][1]: E0001000, CID: B105E00D, PID: 000BB002 DWT
    J-Link: ROMTbl[2][2]: E0002000, CID: B105E00D, PID: 000BB00E FPB
    J-Link: ROMTbl[2][3]: E0000000, CID: B105E00D, PID: 000BB001 ITM
    J-Link: ROMTbl[1][1]: E0041000, CID: B105900D, PID: 001BB975 ETM-M7
    J-Link: ROMTbl[0][1]: E0040000, CID: B105900D, PID: 000BB9A9 TPIU-M7
    J-Link: Cache: Separate I- and D-cache.
    J-Link: I-Cache L1: 16 KB, 256 Sets, 32 Bytes/Line, 2-Way
    J-Link: D-Cache L1: 16 KB, 128 Sets, 32 Bytes/Line, 4-Way
    J-Link: Found SW-DP with ID 0x5BA02477
    J-Link: Found SW-DP with ID 0x5BA02477
    J-Link: AP map detection skipped. User manually configured AP map.
    J-Link: AP[0]: AHB-AP (IDR: Not set)
    J-Link: AP[0]: Core found
    J-Link: AP[0]: AHB-AP ROM base: 0xE00FD000
    J-Link: CPUID register: 0x411FC270. Implementer code: 0x41 (ARM)
    J-Link: Found Cortex-M7 r1p0, Little endian.
    J-Link: FPUnit: 8 code (BP) slots and 0 literal slots
    J-Link: CoreSight components:
    J-Link: ROMTbl[0] @ E00FD000
    J-Link: ROMTbl[0][0]: E00FE000, CID: B105100D, PID: 000BB4C8 ROM Table
    J-Link: ROMTbl[1] @ E00FE000
    J-Link: ROMTbl[1][0]: E00FF000, CID: B105100D, PID: 000BB4C7 ROM Table
    J-Link: ROMTbl[2] @ E00FF000
    J-Link: ROMTbl[2][0]: E000E000, CID: B105E00D, PID: 000BB00C SCS
    J-Link: ROMTbl[2][1]: E0001000, CID: B105E00D, PID: 000BB002 DWT
    J-Link: ROMTbl[2][2]: E0002000, CID: B105E00D, PID: 000BB00E FPB
    J-Link: ROMTbl[2][3]: E0000000, CID: B105E00D, PID: 000BB001 ITM
    J-Link: ROMTbl[1][1]: E0041000, CID: B105900D, PID: 001BB975 ETM-M7
    J-Link: ROMTbl[0][1]: E0040000, CID: B105900D, PID: 000BB9A9 TPIU-M7
    J-Link: Cache: Separate I- and D-cache.
    J-Link: I-Cache L1: 16 KB, 256 Sets, 32 Bytes/Line, 2-Way
    J-Link: D-Cache L1: 16 KB, 128 Sets, 32 Bytes/Line, 4-Way
    J-Link: connected to target device
    J-Link: Reset: Halt core after reset via DEMCR.VC_CORERESET.
    J-Link: Reset: Reset device via AIRCR.SYSRESETREQ.
    J-Link: J-Link: Flash download: Bank 0 @ 0x08000000: Skipped. Contents already match
    Executed J-Link command "SelectTraceSource=1"
    J-Link: Start: Initializing trace pins
    J-Link: End: Initializing trace pins
    J-Link: Using dedicated IP streaming channel for max. trace throughput. J-Trace: IP 192.168.1.103:19030. Host IP: 192.168.1.102:62058.
    Debug.Continue();
    J-Link: Start: Initializing trace pins
    J-Link: End: Initializing trace pins
  • Hi Marcus,

    How it looks like when tracing is running correctly in Ozone can be seen in the following video: youtube.com/watch?time_continue=1&v=qdjvSfpxwyI

    I assume, the trace pins may not be correctly configured. As written in my initial post, we have TRACED0 on PG13 and not on PE3.


    This might be the source of the problem.
    On the STM32F7 eval boards trace pins are connected to PE2-PE6. That is what the example is based on.
    If you use another configuration you need to set it correctly in the JLinkScript.

    So enable clocking on Port G as well and replace the PE3 config with the PG13 config and you should be good to go.

    Best regards,
    Nino
    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.
  • Hi Marcus,

    Keil just contacted us in your regard instead of simply answering your question.
    So before waiting for them to forward you our answer, here it is:

    To get J-Trace running with uVision and the STM32F7 series you need to do the same trace init you need to do for the uLink:
    keil.com/support/man/docs/ulin…linkpro_STM32F4xx_ETM.htm

    So just like with Ozone you need to initialize the trace clock and all four trace data pins.
    After that everything should work as expected.
    Keep in mind that on your boards the trace pins are mapped differently, so you need to take that into account in your trace.ini.

    Best regards,
    Nino
    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.
  • Hi Nino,

    ok: I tried another hardware (STM32F411) with standard trace pin mapping (PE2 ... PE6) and - when Ozone is paused - I get

    Trace clock: 39990 kHz
    Half-sync detection: 0xFFF7FFF7 (O.K. half-sync pattern detected)
    Last incorrect half-sync sampled: 0x17C21B42

    When Ozone is running
    Half-sync detection:0xFF17024B (Not O.K. no half-sync pattern detected)

    On the STM32F767 things still seem to be wrong/unchanged. I configured the non-standard trace pin mapping (see JLinkScript attached) which should be correct i.m.o.

    The detected trace clock is
    Trace clock:8080 kHz

    Is it possible that the Zener protection diodes may cause this? How can I reduce the trace clock in order to check that?

    Kind regards

    Marcus
    Files
  • Hi Marcus,

    ok: I tried another hardware (STM32F411) with standard trace pin mapping (PE2 ... PE6) and - when Ozone is paused - I get


    Great to hear that tracing is generally working with your J-Trace Pro.
    Now lets try to transfer this to the STM32F7.

    When Ozone is running
    Half-sync detection:0xFF17024B (Not O.K. no half-sync pattern detected)

    To clear this up.
    This is expected. When your application is running you are getting trace data other than half synchs.
    So whenever you halt your application you should get only half-synchs. When the application runs you get sometimes half-synchs.

    On the STM32F767 things still seem to be wrong/unchanged. I configured the non-standard trace pin mapping (see JLinkScript attached) which should be correct i.m.o.


    It looks mostly correct indeed. One little "mistake" I noticed was that for PG13 when setting the alternate function mode to AF0 you wrote to GPIOG_AFRL register instead of GPIOG_AFRH
    register.
    So correct would be :

    C Source Code

    1. v = JLINK_MEM_ReadU32(GPIOG_AFRH_Addr);
    2. v &= ~(15 << (4 * 5 )); // Select alt func 0
    3. JLINK_MEM_WriteU32(GPIOG_AFRH_Addr, v);


    Where GPIOG_AFRH_Addr = 0x48001824;

    But according to the user manual the reset value is 0x00 anyways so it should not make any difference.

    Is it possible that the Zener protection diodes may cause this? How can I reduce the trace clock in order to check that?


    This sounds very much like the Zener are creating the problem.
    Easiest would be to simply remove them.
    Should you need isolation between target and debug probe we offer a J-Trace Isolator: segger.com/products/debug-prob…olators/j-trace-isolator/

    To reduce the trace clock further you would need to edit the PLL init in the Embedded Studio example project and rebuild it.
    But there is no guarantee that a lower clock will solve any issue, depending on how intrusive the Zener diodes are.
    You could try to change the trace sampling timing together with an Oscilloscope: segger.com/products/debug-prob…ing-up-trace/#tab-27874-2
    But that would be pretty tedious to find a configuration that works with the Zeners and once you increase the Trace clock speed you will see the same issue again and will need a new configuration.
    So we suggest to remove the Zener diodes as then everything should work with the default settings at all trace clock speeds.

    Best regards,
    Nino
    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.
  • Hi Nino,

    thanks a lot for the explanation and the correction for configuring PG13 as TRACE_D0.

    In fact, I removed the Zener diodes on my hardware and I also changed the core clock from 216 MHz to 180 MHz and then down to 100 MHz (motivated by this Segger Wiki page wiki.segger.com/Tracing_on_ST_STM32F769)

    After adjusting GPIO OSPEED
    EdgeTCLK = 3;
    EdgeTD = 3;
    in the trace config JLinkScript, this is the clock that is detected form J-Trace Pro:

    Trace clock: 90000 kHz
    Half-sync detection: 0xD1DDD5DD (Not O.K. no half-sync pattern detected)

    Further reduction of the clock down to 100 MHz:

    Trace clock: 50000 kHz
    Half-sync detection: 0xDDDD5D01 (Not O.K. no half-sync pattern detected)

    Still, half-sync stays as before ...
    I will yet have a look with my oscilloscope.

    Kind regards
    Marcus
  • Hi Nino,

    now some news:
    When I configure 1 bit tracing the half-sync detection is ok and things work - depending on the core / trace clock:

    clock 100 MHz:
    everything seems fine until this error message turns up:

    J-Link: LTRACE (Time since start: 30.996 626, Thread=RX :( Trace packets have been lost and cannot be resent by J-Trace

    With clock increased to 110 MHz or 120 MHz the error message comes much earlier. With clock even higher, the half-sync is still ok, but Ozone does not/hardly receive trace info (%load does not change). Sometimes the J-Trace Pro webserver outputs seems busy (and a few times a saw a strange warning - but could not reproduce).

    Kind regards

    Marcus
  • Hello Marcus,

    That the half-synch detection is not working properly shows that at least one of the trace lanes is either running out of sync to the others or is constantly pulled high/low due to wiring.

    Are all trace lanes approximately the same physical length or are some of them very different?

    From the initial schematics you provided I see that TRACED0 and TRACED1 seem to have additional resistors across to other debug lanes.
    The resistors in question are R901 and R902.
    Is there a particular reason for them to be applied?
    Could you try to remove them and see if the issue resolves?

    Best regards,
    Nino
    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.
  • Hello Nino,

    I now can confirm that one trace lane (D1) is always low. Layout and wiring seems to be ok, though. Thanks for the hint: the resistances 901 and 902 are not populated. I will check whether there is any error in the GPIO/periphery configuration.

    One question: I assumed that when I configure 1 bit tracing (only D0) then I should be able to use a much higher core clock than 100 MHz before getting errors like

    J-Link: LTRACE (Time since start: 30.996 626, Thread=RX :( Trace packets have been lost and cannot be resent by J-Trace

    Or is this error expected (because of using only 1 lane)?

    Kind regards

    Marcus
  • This thread will now be closed and continued per e-mail to keep a singular communication channel.

    Edit: The solution was that the programmed application reconfigured the trace pins after they have been configured once by the JLinkScript.
    Removing that code solved the issue and stable trace could be achieved.

    Best regards,
    Nino
    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.