AnsweredAssumed Answered

program can't reach main(), stucks in arm-none-eabi lib

Question asked by ostap on Nov 14, 2016
Latest reply on Nov 14, 2016 by ostap

I'm trying to start debugging of the program on my bare-metal board but program runs somewhere in arm-none-eabi libraries without source code (particularly in __divsi3 or __aeabi_dadd) and I cannot catch it with debugger in any reasonable point with source code. I tried to set break-points at Reset_Handler in startup_stm32f051x8.S, at SystemInit() in system_stm32f0xx.c from CMSIS, at main.c() - nothing works, after I start debugging - program runs continuously and if I stop it with debugger and do several steps then debugger says:

Single stepping until exit from function __divsi3,
which has no line number information.
Single stepping until exit from function __aeabi_dadd,
which has no line number information.

Debugger shows me message 
No source available for "(gdb[3].proc[42000].threadGroup[i1],gdb[3].proc[42000].OSthread[1]).thread[1].frame[0]"
but I can stop program execution and do steps. As I understand this message telling me that the program is running in libs without source code available.

So the question is how to debug in this situation and let program reach at least  SystemInit() or main()?
Also the question - can GDB stop the CPU in ResetHandler in start-up file? I'm thinking can program run somewhere in interrupt handler... but all interrupts from peripherals I use like USART should be disabled before peripheral configuration in main() (I use standard generated by Cube code) and program can't reach this.

About HW and IDE:
stm32f051C8 controller, Eclipse + GCC + arm-none-eabi lib +  GDB
In the project I use startup_stm32f051x8.S and STM HAL drivers from STM Cube (project generated by Cube and adopted to IDE described above)
I exclude basic HW problems because CPU is running and can be halted by HW debugger.