Sunday, February 18th 2018, 8:29pm UTC+1

You are not logged in.

  • Login
  • Register

Dear visitor, welcome to SEGGER Forum. If this is your first visit here, please read the Help. It explains how this page works. You must be registered before you can use all the page's features. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

Marcus

Beginner

Date of registration: Jan 20th 2016

Posts: 21

1

Wednesday, January 10th 2018, 10:00am

[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
Marcus has attached the following images:
  • screenshot.png
  • trace_connector.png

SEGGER - Nino

Super Moderator

Date of registration: Jan 2nd 2017

Posts: 693

2

Wednesday, January 10th 2018, 11:37am

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.
https://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: https://www.segger.com/products/debug-pr…tting-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

Marcus

Beginner

Date of registration: Jan 20th 2016

Posts: 21

3

Wednesday, January 10th 2018, 4:10pm

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 (http://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
Marcus has attached the following image:
  • error.png

SEGGER - Nino

Super Moderator

Date of registration: Jan 2nd 2017

Posts: 693

4

Thursday, January 11th 2018, 10:20am

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

Marcus

Beginner

Date of registration: Jan 20th 2016

Posts: 21

5

Thursday, January 11th 2018, 4:50pm

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

SEGGER - Nino

Super Moderator

Date of registration: Jan 2nd 2017

Posts: 693

6

Thursday, January 11th 2018, 5:31pm

Hi Marcus,

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

Quoted

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

SEGGER - Nino

Super Moderator

Date of registration: Jan 2nd 2017

Posts: 693

7

Friday, January 12th 2018, 10:44am

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:
http://www.keil.com/support/man/docs/uli…M32F4xx_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

Marcus

Beginner

Date of registration: Jan 20th 2016

Posts: 21

8

Friday, January 12th 2018, 11:44am

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
Marcus has attached the following file:

SEGGER - Nino

Super Moderator

Date of registration: Jan 2nd 2017

Posts: 693

9

Friday, January 12th 2018, 12:14pm

Hi Marcus,

Quoted

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.

Quoted

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.

Quoted

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/C++ Source code

1
2
3
v  =  JLINK_MEM_ReadU32(GPIOG_AFRH_Addr);
  v  &= ~(15 << (4 *  5 ));              // Select alt func 0
  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.

Quoted

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: https://www.segger.com/products/debug-pr…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: https://www.segger.com/products/debug-pr…ce/#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

Marcus

Beginner

Date of registration: Jan 20th 2016

Posts: 21

10

Friday, January 12th 2018, 2:56pm

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 https://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

Marcus

Beginner

Date of registration: Jan 20th 2016

Posts: 21

11

Friday, January 12th 2018, 3:25pm

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

SEGGER - Nino

Super Moderator

Date of registration: Jan 2nd 2017

Posts: 693

12

Monday, January 15th 2018, 10:54am

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

Marcus

Beginner

Date of registration: Jan 20th 2016

Posts: 21

13

Monday, January 15th 2018, 6:15pm

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

SEGGER - Nino

Super Moderator

Date of registration: Jan 2nd 2017

Posts: 693

14

Wednesday, January 17th 2018, 2:35pm

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