OMAP3503: Cannot connect to ETM/ETB for trace debugging

Hello Maciej,

Sorry, but this part does not have ongoing support from TI anymore, as indicated in the product page. You may want to check the Code Composer Studio release notes and see if OMAP3503 is supported by version 9.3. 

Regards,

Jianzhong

I can't access the release notes for any v9 release for some reason, but both v8 and v10 quote OMAP device support, v1.0.9 and v1.1.0 respectively.

Let me loop in CCS team for further help.

According to the documentation I have, ETB trace is not supported on OMAP3x

Actually it may be supported. I am following up with engineering. Sorry for the confusion

The OMAP35x Technical Reference Manual does indeed show the ETM to be present.

Ki is away at the moment.

I took a look at my CCS install and I noticed that the configuration for OMAP3530 and OMAP3503 is different when it comes to the ETB.

The capture above is the detailed target configuration and you can see the ETB for the 3530.

What I would suggest is to add an ETB to your 3503 configuration.

Open your ccxml file

select the advanced tab at the bottom

select the CS_DAP_PC_0 in the tree

click the add button

select subpath

give it a name, maybe subpath_etb

click finish

select the new subpath in the tree on the left

check the "pseudo" box on the right

click the Add button again

select the Cpus tab

scroll down and select CS_ETB

Give it the name CCETB_0

Click finish

set the properties like this

Save your ccxml file

Now try using trace again with ETB as the receiver.

John

Hi John,

That seems to have gotten us much closer than before, but now we're getting errors about a lack of AET resource when attempting to start a PC Trace.

I've tried disabling as many hardware breakpoint resources as I'm aware of:

with no effect.

Kind regards,
Maciej

Maciej,

I am not sure what to suggest next.  Disabling breakpoints would have been my next suggestion but you have already done that.  Basically that AET (Advanced Event Triggering) message means that the debug stack is not able to allocate the hardware resources (hw breakpoints, triggers...) it needs to enable trace.  

I think the reality is that no one on our side has tried trace on OMAP3505.  I know people used it on OMAP3530 back years ago but given that the ETB was not even in the target configuration for OMAP3505 I doubt it was tried on OMAP3505.  Could be that the underlying code that defines what breakpoints/triggers a device has does not have the necessary info in it for enabling trace.  I have to be honest that it will be tough to get someone to look at this as the device no longer has design support and we don't have one in our lab.

I can try poking around and see if I can find something that is wrong.

Regards,

John

I'm not really sure why the ETB was was included in the TRM then, unless there was a footnote somewhere about it not being supported/tested on the OMAP3503 that I missed.

Please let me know if you manage to find something though.

The TRM is really for the device.  So I bet the ETB is physically there.  The issue would be when the device support package for this device was done for CCS the info for the ETB was not added or tested.  I would bet that the ETB was tested using Lauterbach as that toolset was quite commonly used for OMAP3 class devices.

Regards,

John

Maciej,

I took a look at some of the lower level content and I could not find anything obvious that would help.

Regards,

John

Thank you for your effort. Looks like we'll have to make do without!

Unfortunately that is the case.