Finding the faulting PC

ChibiOS public support forum for topics related to the STMicroelectronics STM32 family of micro-controllers.

Moderator: RoccoMarco

Post Reply
Hildy
Posts: 8
Joined: Wed May 01, 2013 12:55 pm

Finding the faulting PC

Post by Hildy »

Hello,

I'm trying to track down a bug in my program; I have a line

>> myconfig->pub.publish((msg_t) &p);

where if I comment it out the program runs (working abnormally of course because data isn't getting out). However, if it's uncommented, I get a bus fault:

$4 = {CPUID = 0x410fc241, ICSR = 0x440f803, VTOR = 0x0, AIRCR = 0xfa050300, SCR = 0x0, CCR = 0x200, SHPR = {0x0, 0x10000000, 0x80000000}, SHCSR = 0x0, CFSR = 0x8200, HFSR = 0x40000000, DFSR = 0x9, MMFAR = 0xffffffff,
BFAR = 0xffffffff, AFSR = 0x0, PFR = {0x30, 0x200}, DFR = 0x100000, ADR = 0x0, MMFR = {0x100030, 0x0, 0x1000000, 0x0}, SAR = {0x1101110, 0x2112000, 0x21232231, 0x1111131, 0x1310132}, unused1 = {0x0, 0x0, 0x0, 0x0, 0x0}, CPACR = 0x0}

obviously -1 is an invalid address, but I don't get a useful PC to isolate where I'm doing this. The stack trace isn't useful:

(gdb) bt
#0 _unhandled_exception () at ChibiOS/os/ports/GCC/ARMCMx/STM32F3xx/vectors.c:208
#1 <signal handler called>
#2 0x55555554 in ?? ()

Putting a breakpoint on that line that seems to be so crucial doesn't help either - it must be optimised somehow.

Any thoughts?
Last edited by Hildy on Sat Jul 20, 2013 4:03 pm, edited 1 time in total.
User avatar
Giovanni
Site Admin
Posts: 14891
Joined: Wed May 27, 2009 8:48 am
Has thanked: 1202 times
Been thanked: 996 times

Re: Finding the faulting PC

Post by Giovanni »

Hi,

Try compile the SW with no optimizations (-O0) then place a breakpoint on that line. Assuming you didn't do that already of course.

Giovanni
Hildy
Posts: 8
Joined: Wed May 01, 2013 12:55 pm

Re: Finding the faulting PC

Post by Hildy »

I did that.

I found this from FreeRTOS:

http://www.freertos.org/Debugging-Hard- ... llers.html

so I put that debugging code into _unhandled_exception.

Now I'm struggling with the idea that the current thread can change while singlestepping:

Code: Select all

Breakpoint 1, Republisher::RepublisherThread (arg=0x200017a8) at republisher.cpp:17
17         chibios_rt::BaseThread::unlockMutex();
(gdb) display rlist.r_current
1: rlist.r_current = (Thread *) 0x20001948
(gdb) step
chibios_rt::BaseThread::unlockMutex () at ChibiOS/os/various/cpp_wrappers/ch.cpp:382
382       chMtxUnlock();
1: rlist.r_current = (Thread *) 0x20001948
(gdb)
chMtxUnlock () at ChibiOS/os/kernel/src/chmtx.c:251
251     Thread *ctp = currp;
1: rlist.r_current = (Thread *) 0x20001800
Hildy
Posts: 8
Joined: Wed May 01, 2013 12:55 pm

Re: Finding the faulting PC

Post by Hildy »

ok, after a lot of singlestepping, that turned out to be a very subtle stacksmash. i feel so stupid now.
Post Reply