gdb tracing

[alex31]

Hello, my question in not so much about chibios than with general stm32 debugging (sorry)

I try to make chibios and opencm3 works together, i have a modded vectors.c, and
i can choose in mcuconf.h, to route ISR to be managed by chibios or opencm3, that works with simple
tests, but on larger programs, it fails.

After mcu start, program goes to resetHandler and
loop in. I cannot have stack frame when it fails, so i was wondering if it's possible to automate
gdb (or another tool) so that it trace at source level in a file all the steps of the execution path, step by step.

it would be slow, produce a huge file, but launching that kind of tool overnight will permit me to have a useful dump that i can grep
in the morning.

If someone knows about that kind of tool, let me know !

thanks
Alexandre

[alex31]

Well, i have not been able to find tools to help me, one gdb capacities, gdb tracing looked nice, but is not implemented by
the gdb server i am using.

Anyway, i solve my problem, which was to know why _unhandled_exception handler was called, and to do so, i have
modified _unhandled_exception handler so that i can retrieve the instruction which trigger the exception.

i have slightly modified os/ports/GCC/ARMCMx/STM32F4xx/vectors.c

Code: Select all

static void prvGetRegistersFromStack( uint32_t *pulFaultStackAddress );
static void  _unhandled_exception ( void ) __attribute__( ( naked ) );


void _unhandled_exception (void) {
  __asm volatile
    (
     " tst lr, #4                                                \n"
     " ite eq                                                    \n"
     " mrseq r0, msp                                             \n"
     " mrsne r0, psp                                             \n"
     " ldr r1, [r0, #24]                                         \n"
     " ldr r2, handler2_address_const                            \n"
     " bx r2                                                     \n"
     " handler2_address_const: .word prvGetRegistersFromStack    \n"
     );
}

static void prvGetRegistersFromStack( uint32_t *pulFaultStackAddress )
{
/* These are volatile to try and prevent the compiler/linker optimising them
away as the variables never actually get used.  If the debugger won't show the
values of the variables, make them global my moving their declaration outside
of this function. */
  volatile uint32_t r0;
  volatile uint32_t r1;
  volatile uint32_t r2;
  volatile uint32_t r3;
  volatile uint32_t r12;
  volatile uint32_t lr; /* Link register. */
  volatile uint32_t pc; /* Program counter. */
  volatile uint32_t psr;/* Program status register. */
  
  r0 = pulFaultStackAddress[ 0 ];
  r1 = pulFaultStackAddress[ 1 ];
  r2 = pulFaultStackAddress[ 2 ];
  r3 = pulFaultStackAddress[ 3 ];
  
  r12 = pulFaultStackAddress[ 4 ];
  lr = pulFaultStackAddress[ 5 ];
  pc = pulFaultStackAddress[ 6 ];
  psr = pulFaultStackAddress[ 7 ];
  
  /* When the following line is hit, the variables contain the register values. */
  while (1);
}

When entering hard fault, the stm32 push the value of register on the stack, and loop forever. With this method, you can easily retrieve address of faulty instruction in variable pc,
status in variable psr.

in gdb, after when hard-fault is triggered, you just have to type some commands :

print /x pc => retrieve instruction
disassemble 0x«address» : see the assembly of the address which has triggered exception
info line *0x«address» : see the source code of the line which has triggered exception

I understand that it would be a big job to do that for all mcu * compiler combination, but this has helped me a lot finding my problem.

Alexandre

[chrismerck]

Alexandre,

I tried your sample code on my unhandled exception issue.

I'm trying to get I2C to work (it's been days now).

Anyways, the strange thing is that it looks like the PC is in idle_thread. I don't see how that could possibly cause an exception...

Code: Select all

(gdb) c
Continuing.
^C
Program received signal SIGINT, Interrupt.
0x08009ec4 in prvGetRegistersFromStack (
    pulFaultStackAddress=0x200014f8 <_idle_thread_wa.4416+136>)
    at ../libraries/ChibiOS-RT/os/common/ports/ARMCMx/compilers/GCC/vectors.c:94
94          psr = pulFaultStackAddress[ 7 ];
(gdb) p /x pc
$1 = 0x800a2b0
(gdb) disas  0x800a2b0
Dump of assembler code for function _idle_thread:
   0x0800a2a0 <+0>:     push    {lr}
   0x0800a2a2 <+2>:     sub     sp, #12
   0x0800a2a4 <+4>:     str     r0, [sp, #4]
   0x0800a2a6 <+6>:     ldr     r0, [pc, #12]   ; (0x800a2b4 <_idle_thread+20>)
   0x0800a2a8 <+8>:     bl      0x800a280 <chRegSetThreadName>
   0x0800a2ac <+12>:    bl      0x800a180 <port_wait_for_interrupt>
   0x0800a2b0 <+16>:    b.n     0x800a2ac <_idle_thread+12>
   0x0800a2b2 <+18>:    nop
   0x0800a2b4 <+20>:    cbnz    r0, 0x800a2d8 <chSysInit+24>
   0x0800a2b6 <+22>:    lsrs    r0, r0, #32
End of assembler dump.

Any tips?

[alex31]

i have never meet case where pc was in idle thread when hardfault occurs ...

did you try :

Code: Select all

info line *pc

to see the source line of what can cause your issue in idle thread ?

did you enable all of the chibios check to catch problem like stack overflow ?

Alexandre

[alex31]

Your i2c problem is not the infamous 1 byte read bug ? :

http://forum.chibios.org/phpbb/viewtopic.php?f=3&t=25&start=240#p1830

if so, it is simple to fix (just read 2 bytes).

Alexandre

[chrismerck]

Thanks. Good to know about the 1byte read bug, I'll look out for that.

But my problem turned out to be stack-overflow, revealed once I enabled run-time stack checking.


-Chris

[Giovanni]

Hi,

It is not a bug but an hardware limitation of the F1 devices.

Giovanni