I am trying to set up a debug session and I have my startup script where I have defined the basic address details for each and every core sight component in the design. But unfortunately, ETFs and FUNNELs, I get an error stating 'Coresight TMC Identification Wrong' followed by the address that I have specified when I execute the 'system.attach' command. I have cross-checked the address and it is correct. Any help would be appreciated.
Thank you.
The identification registers on the chip are not providing values expected by TRACE32 PowerView. If it were the funnel misconfigured, the error message should be "Coresight FUNNEL Identification register wrong", so I would suspect the ETF.
Are you seeing the same addresses listed when running SYStem.DETECT.DAP?
Depending on your revision, you might have a subfolder, demo/arm/etc/etb which has ETB/ETF/ETR helper scripts, although these would probably only be useful after your debug configuration is mapped correctly.
Funnel.
Make sure you are including the port number for each ATB [AMBA Trace Bus] source in your funnel configuration. One way to do this is by double clicking each port in SYStem.CONFIG.FUNNEL1.view ATBSource. The ETF and funnel components can sometimes have in-depth configuration options, such as SYStem.CONFIG.ETF.StackMode, although these are usually automatically set and not needed as part of a PRACTICE script.
ETF.
There shouldn't be much to configure. There is the possibility this Coresight component is self-reporting as another type. If you reset the configuration (in other words, leave out the funnels and ETFs), then attach, break, and do a Data.dump of the address for each problematic Coresight component, there should be something in the identification registers (address + 0xFC0 to 0xFFF). By cross-referencing what you find here with Arm's documentation—the Coresight Components TRM or Embedded Trace Macrocell Architecture Specification or Coresight TMC TRM—you can see (a) that a component actually exists where expected, and (b) that the component is correctly identified and configured. (The configuration registers would be at a different address offset than the ID registers.) SYStem.DETECT.DAP should do a lot of the heavy lifting of automatically identifying and even configuring each component based on how it is self-reporting, so this paragraph is only relevant if a device has an improperly configured, unusual, or newly released component.
Less frequently, chip manufacturers change the trace subsystem layout between chip revisions or even have undocumented sources/links/sinks. Subsystem changes should be listed in an errata or documentation history.
A few rare targets have trace subsystems that are completely powered down and even disabled (2'b10 instead of 2'b11) in the CoreSight ROM table, and these must be first powered up per the SoC documentation, then configured in TRACE32 PowerView.
Any advanced startup sequences or unusual configuration details are usually included in a TRACE32 installation, in the demo/arm/hardware subfolder or as part of the configuration that occurs when a specific CPU is selected in the software. Can your target be found in that subfolder, or are you defining the chip completely from a base architecture e.g. SYStem.CPU CortexM4F?
Last note: Make sure ETM.state or any related commands (ETMLA, ETMOnChip) have the correct details. As part of ETM.Register, you should be able to see the configuration for the ETF if it is properly communicating with the debugger.
Emailing Lauterbach support would be your best bet at a quick resolution.
