Hi,
On Thu, 24 Apr 2025 at 22:49, Tushar Rane tusharrane@gmail.com wrote:
I am trying to get OpenCSD working to decode traces for code running on Dual core Arm Cortex-R8, all running in the context of Nucleus OS. I am running into some issues as described below; will appreciate any advice/suggestions.
I have been able to get some of this working. So far following is the progress:
- OpenCSD library version: 1.5.5
- Using c_api_pkt_print_test.c test program to configure OpenCSD library and decode. Configuration or changes done in c_api_pkt_print_test.c::create_decoder_etmv4 for the Arm Cortex R8.
Not using snapshot, but hard coded the mem_file_path and trace_file_path for my Arm Cortex R8 files. Logs are attached at the end of this message for reference.
- Configuration from the code running on Arm Cortex-R8 for ETM, ETB, ETMFUN, Replicator, seems to be working.
- Able to get ETB traces successfully.
- Changed c_api_pkt_print_test.c and was able to compile and get some decoding done.
- In the output of "c_api_pkt_print_test -raw -decode", the addresses can be co-related to the executed code, so it seems to be working so far till here.
For example: Frame Data; Index 3984; ID_DATA[0x06]; e3 06 19 96 60 02 00 81 03 9a 04 00 ff ff Idx:3981;[ 0x96 0xDF 0xE3 ];I_ADDR_S_IS1 : Address, Short, IS1.; Addr=0x00000000201FE3BE ~[0xE3BE] Idx:3985;[ 0x06 0x19 ];I_EXCEPT : Exception.; Data Fault; Ret Addr Follows; Idx:3987;[ 0x96 0x60 ];I_ADDR_S_IS1 : Address, Short, IS1.; Addr=0x00000000201FE3C0 ~[0xC0] Idx:3989;[ 0x02 0x00 ];I_TIMESTAMP : Timestamp.; Updated val = 0x0 The “Addr=” can be co-related to the executed code before the trace was collected.
Following are the issues encountered and the post here is to seek any ideas on what could be causing these and what could be to be done to fix them.
a. In the output for “c_api_pkt_print_test -raw -decode”, the decoder is not generating any OCSD_GEN_TRC_ELEM_INSTR_RANGE elements, which Is the main issue here.
c_api_pkt_print_test is an internal test program to check the functionality of the C-API wrapper for the main C++ library. It is not designed for generic trace decode. The issue you are seeing is that for the -decode operation to succeed, program images that match the trace supplied most be present. The decode operation requires the program image to work correctly. See the OpenCSD documents and ETM documents for more information on this.
You will note that the program points to files in the "snapshots" directory for pull in both trace binary files and memory dumps of executed code.
If you wish to decode your own trace, then create a snapshot - as supplied in the tests directory - that contain both trace data, memory images, and register configuration files for the system you are using. See the examples supplied and the documentation for this format.
You can then us the trc_pkt_lister program which is designed to process these snapshots.
b. There are multiple occurrences of following errors: OCSD_ERR_BAD_DECODE_PKT (along with I_COND_FLUSH), OCSD_ERR_COMMIT_PKT_OVERRUN
Idx:441;[ 0x9B 0x21 0xDB 0x21 0x20 ];I_ADDR_L_32IS1 : Address, Long, 32 bit, IS1.; Addr=0x000000002021DB42; Idx:446;[ 0x43 ];I_RESERVED_CFG : Reserved header for current configuration.[I_COND_FLUSH]
This packet is invalid when non conditional tracing is disabled. Looking at the ID regs for your ETM, you device does support tracing of conditional non branch instructions, but the TraceInfo packet indicates that it is not active. The decoder will error out due to this inconsistency.
Looking at the files you provide the appear to only be flush packets appearing - this is clearly incorrect if there are no C & R packets. This may indicate corrupt trace or a bug in your ETM.
I am also concerned about the speculative trace. This appears to commit very few elements until the max speculation depth is reached. This is not what I would ordinarily expect. Additionally the COMMIT elements appear to be triggered by ASYNC packets, appearing after them which may be causing some of the speculation overrun in the decoder.
Regards
Mike
DCD_ETMV4_0006 : 0x0019 (OCSD_ERR_BAD_DECODE_PKT) [Reserved or unknown packet in decoder.]; TrcIdx=446; CS ID=06; Unknown packet type.Frame Data; Index 448; ID_DATA[0x06]; 02 00 f7 da 2f 03 81 83 00 00 00 00 43 96 29 Idx:448;[ 0x02 0x00 ];I_TIMESTAMP : Timestamp.; Updated val = 0x0 Idx:448; TrcID:0x06; OCSD_GEN_TRC_ELEM_NO_SYNC( [bad-packet]) Idx:450;[ 0xF7 ];I_ATOM_F1 : Atom format 1.; E
c. On running just “c_api_pkt_print_test -raw” (no decode), multiple OCSD_ERR_INVALID_PCKT_HDR errors are observed, along with I_COND_FLUSH are observed: PKTP_ETMV4I_0006 : 0x0014 (OCSD_ERR_INVALID_PCKT_HDR) [Invalid packet header]; TrcIdx=460; CS ID=06; Idx:460; I_RESERVED_CFG : Reserved header for current configuration.[I_COND_FLUSH]
However, conditional Instruction Tracing is disabled (as seen below) , so it's unclear why I_COND_FLUSH above are observed. Could I_COND_FLUSH be throwing off the decoder?
NOTES:
I did run a test by configuring the processor to stall, setting TRCSTALLCTLR to 0x50c (in case traces were being dropped and processor stalling helped). However that did not make any difference.
CONFIGURATION DONE IN CODE RUNNING ON ARM CORTEX-R8:
// INSTP0 = 0 (Only branches are P0 instructions) // BB = 0 (Branch broadcast mode disabled) // CCI = 0 (cycle counting in instruction trace disabled) // CID = 1 (Context ID tracing enabled) // COND = 0 (Conditional instruction tracing disabled) // TS = 1 (Global timestamp tracing enabled) // RS = 1 (Return stack enabled) // DA = 0 (Data address tracing disabled) // DV = 0 (Data value tracing disabled) TRCCONFIGR = 0x1841;
// disable all event tracing TRCEVENTCTL0R = 0; TRCEVENTCTL1R = 0;
// ISTALL = 0 (Do not stall processor) // DSTALL = 0 (Do not stall processor) // LEVEL = 0 (Lowest level, where zero invasion occurs) // the risk of overflow) TRCSTALLCTLR = 0;
// Enable trace synchronization every 256 bytes of trace TRCSYNCPR = 0x8
//Trace ID = 6, only on trace stream from one Cortex R8 core. TRCTRACEIDR = 6;
// Disable the timestamp event. The trace unit still generates // timestamps due to other reasons such // as trace synchronization TRCTSCTLR = 0;
// Enable ViewInst to trace everything, with the Start/Stop logic // started // EXLEVEL_S3 = 0 (Enable ViewInst in this exception level. // Highest privilege level. FW runs at this level) // TRCERR = 1 (System error exception is always traced regardless of // the value of ViewInst) // SSSTATUS = 1 (Start/stop logic is in the started state) // TYPE = 0 (Single selected resource) // SEL = 1 (Selects the resource number 1, which always returns TRUE) TRCVICTLR = 0xa01
// No address range filtering for ViewIns TRCVIIECTLR = 0;
// No start or stop points for ViewInst TRCVISSCTLR = 0;
// enable ETM TRCPRGCTLR = 1;
Configuration for ETMv4 done in c_api_pkt_print_test.c
trace_config.arch_ver = ARCH_V7; trace_config.core_prof = profile_CortexR; trace_config.reg_configr = 0x1841; printf("trace_config.reg_configr = 0x%x", trace_config.reg_configr); trace_config.reg_traceidr = 0x6; // CRT = 6 if(test_trc_id_override != 0) { trace_config.reg_traceidr = (uint32_t)test_trc_id_override; } test_trc_id_override = trace_config.reg_traceidr; /* remember what id we actually used */ trace_config.reg_idr0 = 0x6001eff; trace_config.reg_idr1 = 0x4100f400; trace_config.reg_idr2 = 0x420084; trace_config.reg_idr8 = 0x40; trace_config.reg_idr9 = 0x40; trace_config.reg_idr10 = 0x40; trace_config.reg_idr11 = 0x11; trace_config.reg_idr12 = 0x20; trace_config.reg_idr13 = 0x0; /* create an ETMV4 decoder - no context needed as we have a single stream to a single handler. */ return create_generic_decoder(dcd_tree_h,OCSD_BUILTIN_DCD_ETMV4I,(void *)&trace_config,0);Attached following logs:
Output of “c_api_pkt_print_test -raw -decode” - 5.raw.decode.newoutput.log Output of “c_api_pkt_print_test -raw” - 5.raw.newoutput.log
I would appreciate any feedback regarding this to help get the needed output from the decoder. _______________________________________________ CoreSight mailing list -- coresight@lists.linaro.org To unsubscribe send an email to coresight-leave@lists.linaro.org