Initialization to route ETM/ITM trace to external pins

[ncputhuff]

Is there an init script or code sample that will show the complete steps for exporting ETM/ITM trace data to the package pins?

Using ARM DS-5 with Vybrid Tower system and CMSIS-DAP connection, running 'hello_world' example.   Win32 host.

I have the IOMUXC regs programmed (using this script: https://community.freescale.com/servlet/JiveServlet/download/368280-268789/vf6twr_a5_ddr_etm.txt.zip as a starting point)

and can unlock and program the TPIU, ATB funnels and ETM's, and enable the clocks to these sections via the CCM_CCPGR's and enable trace clock via CCM_CSCDR3.

I'm getting a TRACECLK on the CoreSight connector, but the data signals are stubbornly refusing to wiggle (unless I put the TPIU into test pattern mode -- this will put the expected activity on the TRACEDATA pins).

VYBRIDRM.pdf section 20.9 briefly mentions "The Platform Trace Control (Pltf-TCTL) module controls the trace flow..." and details (4) bits - that disable TPIU trace or enable SWO trace, but this hasn't yielded the magic bit to make it all work.

Is there a known-good script or equivalent to make this work?

[ncputhuff]

Update: 

+ The CA5's ETM/ITM data can be routed to the ETB and it works as expected.

+ Placing the TPIU into continuous mode will generate empty frames at the TRACECLK rate (this is seen on the trace connector) -- so the TPIU's formatter is working correctly.

- Still cannot get ETM/ITM data to the connector (as though the TPIU isn't getting any input data to format and export).

The VYBRIDRM.pdf, section 20.9 "Trace Architecture" block diagram shows that the CA5's ETM/ITM data is passed to the TPIU through logic that's in a separate clock domain called "Fastest System Clock which doesn't track the CM4".  It's acting like that clock is disabled.   I can't tell from the docs which clock this actually is, so I've tried enabling EVERY clock in the system.   Still not working.

It really seems like this is outside of the stuff that's contained in the ARM docs for ETM/ITM/FUNNEL/TPIU, and I haven't found the magic bit in the docs for Vybrid.

Freescale?    Is there some undocumented bit that needs to be set?  

I'm stuck.

Thanks much.

[rendy]

Hi ncputhuff,

I will need more time for digging deeper into this - let's say a week, is it OK for you to wait or are you in hurry?

Rene

[ncputhuff]

Hello -- Rene?

Still stuck here, and I've had no contact from any tools liaison or other Freescale help.

Coming up on a month of lost time... could this please be looked at?

Thank you.

[rendy]

Sorry, we are still working on it, could you please meanwhile look on this thread if it doesn't help you?

Vybrid ETM trace doesn't work

[ncputhuff]

That page is showing "Unauthorized" and blocking my view:

"Access to this place or content is restricted. If you think this is a mistake, please contact your administrator or the person who directed you here."

I've tried 2 different browsers, same result.

Suggestions..?

[naoumgitnik]

Dear NC PUTHUFF,

• Rene's link is to the space for internal use only, intended for the Freescale FAEs. rendy, if that link is relevant for this thread and contains no secrets, perhaps, you may copy its results into this thread, otherwise the only way would be via our FAE local to NC PUTHUFF.
• Or NC PUTHUFF might wait until Rene is done with that issue and posts his results here as well.

BTW, perhaps the https://community.freescale.com/message/383309?et=watches.email.thread#383309 thread can help?

Regards, Naoum Gitnik.

[ncputhuff]

That page is also blocked from view.

[naoumgitnik]

Dear NC PUTHUFF,

Sorry, I missed the point that the thread was private but it looks like the information in it is actually not.

-----------------------------------------------

I could enable tracing with DS-5 without replacing damping resistors so far.

The reason why I failed to enable it was that I used Ethernet to connect DSTREAM. DSTREAM should be connected through USB to enable tracing.

...

So the 1st step that confirming tracing with DS-5 was resolved.

However the customer still has problems that some TPIU registers couldn't be accessed. In my environment, I couldn't access these registers.

Can you access them?

Could you, please, give me some advices for this?

...

Tracing is now working on the customer side by enabling trace interface IOMUX.

Regarding TPIU register access failure I asked you, this was because customer sent me wrong base address for TPIU. now we can access TPIU registers. All issues are closed. Thank you for your time.

...

For Vybrid part, no more register setting is required.

However some configuration on debugger software would be needed.

In case of DS-5 + DSTREAM, you may need DTSL (Debug and Trace Service Layer) configuration.

In my experience, "Trace capture method" should be "On Chip Trace Buffer (ETB)", then it works.

...

In addition, I have only tried tracing BootROM contents, not for software project.

So, only executed the .ds script file (attached), then run processor or execute instruction by step.

-----------------------------------------------------------

Hopefully it helps.

Regards, Naoum Gitnik.

[ncputhuff]

Thanks Naoum -- but that script is approximately the same as the two others in this thread.

It really seems like there's a clocking or datapath-enable issue for the trace data between the FUNNEL and the TPIU.

Off-chip trace *had* to have been verified in Vybrid at some point, but maybe some key step didn't make it into the released documents (?)

Could you please check with the chip design team, ARM tools vendor liaison, or any internal documentation to determine this missing configuration step?

Thanks in advance

[juangutierrez]

It seems before enabling the ETM you should unlock, the TPIU, A5_Funel, PLTF_funel and ETM modules by writing a key (0xC5ACCE55)

into its corresponding LOCK register.

After unlock you can powerup the ETM, and configure this modules.

1. // tpiu_unlock  
2. *(int32 *)(PLTF_TPIU_BASE + (0x3EC<<2)) = 0xC5ACCE55; // unlock before write 
3. while(*(int32 *)(PLTF_TPIU_BASE + (0x3ED<<2)) != 0x00000001); // check unlock status 
4.  
5.  
6. //ca5_funnel_unlock 
7. *(int32 *)(0x40092000 + 0xFB0) = 0xC5ACCE55; // unlock before write 
8. while(*(int32 *)(0x40092000 + 0xFB4)!=0x00000001); // check unlock status 
9.  
10.  
11. //pltf_funnel_unlock 
12. *(int32 *)(PLTF_FUNNEL_BASE + 0xFB0) = 0xC5ACCE55; // unlock before write 
13. while( *(int32 *)(PLTF_FUNNEL_BASE + 0xFB4) != 0x00000001); // check unlock status 
14.  
15.  
16. //ca5_etm_unlock 
17. CA5ETM.ETMLAR = 0xC5ACCE55; // unlock before write 
18. while(CA5ETM.ETMLSR !=0x1); // check unlock status

[ncputhuff]

Freescale?   Hello?

Is there any way to elevate the priority of this issue?

This issue is in the exact same spot it was on January 26.

I've scoured the reference manual and tried countless iterations to get this working, but the ETM/ITM data cannot get from the CA5 ATB-ASYNC to the TPIU.

I'm guessing it's because there is no clock in this section, but I don't know how to enable it -- or was Vybrid released with broken off-chip trace?

Please...?

[juangutierrez · Accepted solution]

Hi

I have been try to gather information, but I'm not the expert on this. I don't know exactly how to test this feature.

I will share this test, that I got, there is no grant that it will work. Not sure if is for Vybrid of for a previous version but you can check it and try to see if it helps.

[ncputhuff]

Yes!   Very helpful -- in fact: Issue solved.

The code in this archive configures ETM differently than what has worked with other processors, but it results in what looks like valid ETM data on the processor pins.

Thank you!!!

[juangutierrez]

Hi ncputhuff

I'm trying to run the test at my side. As I told you I don't have too much experience with ETM but I would like to have something functional running for continue supporting.

Can you provide some guidelines about how to run the test?

I mean which functions are you calling and if they are different from what I shared in the ETM.zip. what output should I expect?

If you can share your project will be great if not possible I will appreciate if you can provide some guidelines or pseudocode, maybe based on the functions in the ETM.zip project

Thanks in advance

[juangutierrez]

Nice to hear that work for you :smileyhappy:

It would be possible to share your application/test. (I understand if not possible) or at least some information about how to test this functionality.

I mean which pads to look and what to expect and when.

This can guide me for trying at my side and get experience with this and support for others.

[ncputhuff]

Right.   Already doing that.   It's covered in the ARM documentation.   It works on other processors -- but there's *something else* preventing Vybrid from exporting trace data off-chip.

Is there any way to elevate the priority of this issue?     Please?

[mattwronkiewicz]

Naoum,

I am seeing the same problem that nc puthuff described on my own system. I am able to capture on-chip trace in the ETB but not off-chip.

I was under the impression that DSTREAM had the capability to capture off-chip trace. If the trace capture method is set to "On Chip Trace Buffer (ETB)", then the trace packets are not sent through the TPIU. Does off-chip trace work in DSTREAM?

Matt

[karina_valencia]

naoumgitnik previous link is  from private space. Please check it and share  here  information  needed.

[karina_valencia]

rendy please continue with the  follow up.

[ncputhuff]

Hi Rene,

Could you send a message to your ARM tools liaison (or put me in direct contact with them) about this issue?

I suspect that this issue has come up already with a 3rd party tools company and has a known solution -- unless I've made some silly omission in configuring the device.   That should get the ball rolling and off your plate for the moment.  :smileyhappy:

Thanks again.