Hi Zied,
I can't see a reason for the issues based on what you have sent. The trace should start at the exception entry after the exception packet. I have checked the decoder code around the exception handling, but there is no obvious error there. There are no issues that have been logged between the version you are using and the latest decoder version that would suggest what you are seeing is a known issue.
To investigate further please enable the packet logging and raw data logging output from the library. If we can see the individual packets we can determine if there is a fault in the decoder, or if the issue lies elsewhere. The example test program shows how to enable this support.
Thanks
Mike
________________________________ From: Zied Guermazi zied.guermazi@trande.de Sent: 02 April 2021 20:39 To: Mike Leach Mike.Leach@arm.com Subject: opencsd: issue when decoding exceptions in ARMv7 M
hi Mike
I have observed a strange behavior opencsd decoder when decoding traces of an IRQ on an stm32f4 (armv7 M4) MCU.
let me first describe the context:
here is the vector table with the list of address of exceptions handlers:
08000000 <g_pfnVectors>: 8000000: 30 08 00 20 33 06 00 08 31 06 00 08 31 06 00 08 0.. 3...1...1... 8000010: 31 06 00 08 31 06 00 08 31 06 00 08 00 00 00 00 1...1...1....... ... 800002c: 31 06 00 08 31 06 00 08 00 00 00 00 31 06 00 08 1...1.......1... 800003c: 31 06 00 08 31 06 00 08 31 06 00 08 31 06 00 08 1...1...1...1... 800004c: 31 06 00 08 31 06 00 08 31 06 00 08 31 06 00 08 1...1...1...1... 800005c: 31 06 00 08 31 06 00 08 31 06 00 08 31 06 00 08 1...1...1...1... 800006c: 31 06 00 08 31 06 00 08 31 06 00 08 31 06 00 08 1...1...1...1... 800007c: 31 06 00 08 31 06 00 08 31 06 00 08 31 06 00 08 1...1...1...1... 800008c: 31 06 00 08 31 06 00 08 31 06 00 08 31 06 00 08 1...1...1...1... 800009c: 31 06 00 08 31 06 00 08 31 06 00 08 31 06 00 08 1...1...1...1... 80000ac: 31 06 00 08 c9 02 00 08 31 06 00 08 31 06 00 08 1.......1...1... 80000bc: 31 06 00 08 31 06 00 08 31 06 00 08 31 06 00 08 1...1...1...1... 80000cc: 31 06 00 08 31 06 00 08 31 06 00 08 31 06 00 08 1...1...1...1... 80000dc: 31 06 00 08 31 06 00 08 31 06 00 08 31 06 00 08 1...1...1...1... 80000ec: 31 06 00 08 31 06 00 08 31 06 00 08 31 06 00 08 1...1...1...1... 80000fc: 31 06 00 08 31 06 00 08 31 06 00 08 31 06 00 08 1...1...1...1... 800010c: 31 06 00 08 31 06 00 08 31 06 00 08 31 06 00 08 1...1...1...1... 800011c: 31 06 00 08 31 06 00 08 31 06 00 08 31 06 00 08 1...1...1...1... 800012c: 31 06 00 08 31 06 00 08 31 06 00 08 31 06 00 08 1...1...1...1... 800013c: 31 06 00 08 31 06 00 08 31 06 00 08 31 06 00 08 1...1...1...1... 800014c: 31 06 00 08 31 06 00 08 31 06 00 08 31 06 00 08 1...1...1...1... 800015c: 31 06 00 08 31 06 00 08 31 06 00 08 31 06 00 08 1...1...1...1... 800016c: 31 06 00 08 31 06 00 08 31 06 00 08 31 06 00 08 1...1...1...1... 800017c: 31 06 00 08 31 06 00 08 31 06 00 08 1...1...1...
Timer2 (exception number 0x2c) exception handler is located at 080002c8, below is the disassembled code around it
08000290 <bubble_sort>:
void bubble_sort (int *a, int n) { 8000290: b4f0 push {r4, r5, r6, r7} int i, t, s = 1; while (s) { 8000292: 4684 mov ip, r0 8000294: 3804 subs r0, #4 8000296: eb00 0481 add.w r4, r0, r1, lsl #2 s = 0; 800029a: 2700 movs r7, #0 for (i = 1; i < n; i++) { if (a[i] < a[i - 1]) { t = a[i]; a[i] = a[i - 1]; a[i - 1] = t; s = 1; 800029c: 2601 movs r6, #1 800029e: e00c b.n 80002ba <bubble_sort+0x2a> for (i = 1; i < n; i++) { 80002a0: 42a3 cmp r3, r4 80002a2: d009 beq.n 80002b8 <bubble_sort+0x28> if (a[i] < a[i - 1]) { 80002a4: 685a ldr r2, [r3, #4] 80002a6: f853 0b04 ldr.w r0, [r3], #4 80002aa: 4282 cmp r2, r0 80002ac: daf8 bge.n 80002a0 <bubble_sort+0x10> a[i] = a[i - 1]; 80002ae: 6018 str r0, [r3, #0] a[i - 1] = t; 80002b0: f843 2c04 str.w r2, [r3, #-4] s = 1; 80002b4: 4635 mov r5, r6 80002b6: e7f3 b.n 80002a0 <bubble_sort+0x10> while (s) { 80002b8: b125 cbz r5, 80002c4 <bubble_sort+0x34> for (i = 1; i < n; i++) { 80002ba: 2901 cmp r1, #1 80002bc: dd02 ble.n 80002c4 <bubble_sort+0x34> 80002be: 4663 mov r3, ip s = 0; 80002c0: 463d mov r5, r7 80002c2: e7ef b.n 80002a4 <bubble_sort+0x14> } } } } 80002c4: bcf0 pop {r4, r5, r6, r7} 80002c6: 4770 bx lr
080002c8 <TIM2_IRQHandler>:
void TIM2_IRQHandler() { 80002c8: b530 push {r4, r5, lr} 80002ca: b087 sub sp, #28 int values[5] = {0x20,0x10,0x30,0x25,0x15}; 80002cc: ac01 add r4, sp, #4 80002ce: 4d11 ldr r5, [pc, #68] ; (8000314 <TIM2_IRQHandler+0x4c>) 80002d0: cd0f ldmia r5!, {r0, r1, r2, r3} 80002d2: c40f stmia r4!, {r0, r1, r2, r3} 80002d4: 682b ldr r3, [r5, #0] 80002d6: 6023 str r3, [r4, #0] int i; if (TIM_GetITStatus(TIM2, TIM_IT_Update)) 80002d8: 2101 movs r1, #1 80002da: f04f 4080 mov.w r0, #1073741824 ; 0x40000000 80002de: f001 fa85 bl 80017ec <TIM_GetITStatus> 80002e2: b908 cbnz r0, 80002e8 <TIM2_IRQHandler+0x20> ITM_SendValue(2, values[i]);*/
// Clears the TIM2 interrupt pending bit TIM_ClearITPendingBit(TIM2, TIM_IT_Update); } }
when opencsd decodes etm traces it reports following
btrace] ETM trace_element: index= 15079610, channel= 0x2, OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x800044c:[0x8000450] num_i(1) last_sz(4) (ISA=T32) E BR b+link ) [btrace] ETM trace_element: index= 15079617, channel= 0x2, OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x8000282:[0x8000284] num_i(1) last_sz(2) (ISA=T32) E --- ) [btrace] ETM trace_element: index= 15079618, channel= 0x2, OCSD_GEN_TRC_ELEM_EXCEPTION(excep num (0x2c) ) [btrace] ETM trace_element: index= 15079622, channel= 0x2, OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x80002c0:[0x80002c2] num_i(1) last_sz(2) (ISA=T32) E --- ) [btrace] ETM trace_element: index= 15079622, channel= 0x2, OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x80002c2:[0x80002c4] num_i(1) last_sz(2) (ISA=T32) E --- ) [btrace] ETM trace_element: index= 15079622, channel= 0x2, OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x80002c4:[0x80002c6] num_i(1) last_sz(2) (ISA=T32) E --- ) [btrace] ETM trace_element: index= 15079622, channel= 0x2, OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x80002c6:[0x80002c8] num_i(1) last_sz(2) (ISA=T32) E --- ) [btrace] ETM trace_element: index= 15079622, channel= 0x2, OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x80002c8:[0x80002ca] num_i(1) last_sz(2) (ISA=T32) E --- )
instead of starting at 0x80002c8 after the OCSD_GEN_TRC_ELEM_EXCEPTION, it starts at 0x80002c0 which not the start address of the irq handler but rather belonging to the function preceding it in the elf file.
why do we have those 4 OCSD_GEN_TRC_ELEM_INSTR_RANGE preceding the actual irq handler? how should I handle them?
The issue observed with opencsd version 0.12.2-1. is this a known issue?
Kind Regards
Zied Guermazi
--
Zied Guermazi founder
Trande UG Leuschnerstraße 2 69469 Weinheim/Germany
Mobile: +491722645127 mailto:zied.guermazi@trande.de
Trande UG Leuschnerstraße 2, D-69469 Weinheim; Telefon: +491722645127 Sitz der Gesellschaft: Weinheim- Registergericht: AG Mannheim HRB 736209 - Geschäftsführung: Zied Guermazi
Confidentiality Note This message is intended only for the use of the named recipient(s) and may contain confidential and/or privileged information. If you are not the intended recipient, please contact the sender and delete the message. Any unauthorized use of the information contained in this message is prohibited.
-
Mike Leach