I'm developing in c++ for my STM32F3 Discovery board and using std::deque as queue. After trying to debug my code (directly on device with ST-link or in simulator), the code eventually stops at breakpoint before even entering my code in main(). However, SystemInit() configures board just fine..
I've traced this behavior down to using push_back() (and push_front) as commenting it out from code solves the issue. Through disassmebly I found that after using it, the execution stops at breakpoint instruction BKPT and won't move further after resuming execution. This instruction is part of _sysopen() call, with call path:
__main -> __scatterload -> __scatterload_null -> __rt_entry -> __rt_lib_init -> __rt_lib_init_atexit_1 -> _initio -> freopen -> _sysopen
What intrigues me is call to _initio
, which is missing if push_back isn't used, because there is no __rt_lib_init_atexit_1
. Introducing push_back also makes the code size go from 10 kB to 34 kB.
Might this be a result of some bad configuration or should I try another IDE? I'm out of ideas.
I had the same problem. I learnt it has something to do with so called 'semihosting' and that I should build with my project file 'retarget.c' that contains definitions of the functions like '_sys_xxxx()' that are target specific driver level functions (many versions of 'retarget.c' are part of the Keil-MDK and also ca be found on web). So I did but then linker thrown errors similar to this:
I solved this by editing original 'retarget.c' so that functions defined in it will override the ones in Keil-MDK libraries. The new 'retarged.c' is here:
With this version of 'retarget.c' linker was satisfied and my program run w/o problem. Maybe this will help you as well.
Try by checking if scale_buffer contains any element (
scale_buffer.empty()
) before calls to.back()
and.front()
: you are probably reading and writing some garbage, which makes the deque invalid, preparing the ground for a crash when you callpush_back()