TMS570LC4357: Trace issue with Segger JTrace Debug Probes, Non compliant ARM trace implementation

Hi,

I am checking with the emulation dev team to see if the have any specific comments about that. 

However, I found that both Lauterbach and ARM DS-5 mention support for TMS570 ETM

- Page 261 of this document

- ARM DS-5 and DSTREAM

In this case, I suspect the disconnect is in Segger's side, but I will return to this thread in case I get additional information from the dev team. 

Regards,

Rafael 

Hi Rafael,

Segger mentions support for all TMS570 chips that have Cortex R4s (1124, 3137, etc). The TMS570LC4357 with the Cortex R5-F is the unique one that is not supported. I have contacted Green Hills and IAR as well and they report the same. The issue appears to be with the TMS570LC4357 itself.

Hi,

I worked today with a colleague very experienced with the Lauterbach solution and ETM worked without deviation from what is already proven to work in various other target devices. 

We were able to get 32-bit wide ETM operating at the default frequency of 37.5MHz and the only setting that was needed to disable was the termination lines on the pod. We used a TMDX570LC43HDK development kit. 

An .cmm example script for the Lauterbach Trace 32 software is attached for your reference, and it makes use of the TMS570LC4357 configuration already supplied by their tool. 

In the light of this, I would bring this thread to the attention of Segger and see if this brings additional information that may help them move forward with this integration. At any rate, we can't commit to support them via this channel. 

Regards,

Rafael

6404.tms570.zip

Hi Rafael,

Although you performed that test and got 32 bit trace to work using the Lauterbach solution, that is not an indication of what actions are being performed in the background to enable trace. What exactly do you mean without deviation? Are you aware of the steps the Lauterbach debugger performs?

Since you mentioned the 32 bit trace, I assume you are using the MIPI60 connector on the TMDX570LC43HDK. The connector we are using is the ARM Coresight 20, it is the ARM selected standard connector that provides a 4 bit trace bus. Are there any specifications or requirements that the TMS570LC4357's ETM block has? Is there a minimum required bus width? Can you attempt the same test configuring a 4 bit bus width with the Lauterbach solution to see if that is functional?

We are stuck in between Segger and yourself trying to find a solution. We don't mind exploring and configure the necessary blocks ourselves if the Segger solution will not work off the shelf. We are not looking for support with the Segger device in particular, rather support with the ETM implementation on the chip. Since you are the chip manufacturer, we are looking for details regarding the ETM / trace implementation and the necessary steps required to enable trace functionality. There is almost no detail in the TRM of the part, only one reference to the EXTCTL_Out_Port register and the TPIU (Section 2.4.5). Again, just saying that the Lauterbach solution worked in a particular configuration does not indicate the solution is compliant with the ARM ETM standard.

Hi,

Ajay Srivastava said:

Although you performed that test and got 32 bit trace to work using the Lauterbach solution, that is not an indication of what actions are being performed in the background to enable trace. What exactly do you mean without deviation? Are you aware of the steps the Lauterbach debugger performs?

Although I am not privy of the full details on how Lauterbach initializes ETM on this device, we did not use any specific setting or workaround on the tool (nor the tool reported anything that stand out) in the configuration registers or path configuration routing. There is another thread where this is stated as well. 

Ajay Srivastava said:

Since you mentioned the 32 bit trace, I assume you are using the MIPI60 connector on the TMDX570LC43HDK. The connector we are using is the ARM Coresight 20, it is the ARM selected standard connector that provides a 4 bit trace bus. Are there any specifications or requirements that the TMS570LC4357's ETM block has? Is there a minimum required bus width? Can you attempt the same test configuring a 4 bit bus width with the Lauterbach solution to see if that is functional?

Although the ARM Coresight 20 pin connector is indicated for Cortex M cores (reference), we successfully tested the 4-bit data capture on the board + Lauterbach trace pod here. In our first round of tests we did 8, 16 and 32 bit width. 

The only thing that I can see it may trip you is the pinmux configuration of the ETMTRACECLKIN, ETMTRACECLKOUT and ETMTRACECTL pins - the first four ETMDATA pins are exclusive.

Ajay Srivastava said:

We are stuck in between Segger and yourself trying to find a solution. We don't mind exploring and configure the necessary blocks ourselves if the Segger solution will not work off the shelf. We are not looking for support with the Segger device in particular, rather support with the ETM implementation on the chip. Since you are the chip manufacturer, we are looking for details regarding the ETM / trace implementation and the necessary steps required to enable trace functionality.

I could not find any relevant information. I will report back if I find anything relevant.  

Regards,

Rafael

The TMS570LC43x datasheet includes the following procedure required to be followed before accessing TPIU registers. Can you check if this sequence is being followed correctly?

The above screenshot looks like it is from an older datasheet or one for another processor in the family. In the TMS570LC4357 TRM, it actually specifies that the device contains an ETM-R5 module, not the ETM-R4:

In the ARM ETMv1-3.5 specification, there is no reference to unlocking the TPIU registers, only unlocking the ETM registers from the ETMLAR register. (Reference section 3.5.60 of the ARM ETMv3 architecture specification). In the TMS570LC4357 TRM, I could also not find any other reference talking about configuring or unlocking the TPIU besides this section. The TRM also does not specify what the coresight key is. The assumption is that it is 0xC5ACCE55 as specified in section 3.5.60 of the ETMv3 specification. There is also no specified offset at which to write this key. I have tried both 0x3EC (ETMLAR offset) and 0xFB0.

I do not know if the Segger probe is following this procedure to configure TRACECLKIN. It also does not look like setting the ETMTRACECLK is part of the standard procedure to enable trace.

Regardless, I have tried it manually without success by adding the following to our startup sequence which is executed before the trace probe connects:

Again, if you could provide details on all of the steps or the full procedure required to enable trace, that would be helpful for us to narrow down what deviations exist or what is missing. It still does not seem that the chip itself is 100% compliant to the ETMv3 specification without any additional steps.