Hi, On 07/01/16 18:35, Szabó Antal wrote:
I have another, completely unrelated question, maybe not even related to xpcc (I'm not sure). The stm32 I'm programming is on a custom board for a product, that is, I don't use any pre-made boards. One symptom is that sometimes, when I power on the device, nothing happens, it seems like the cpu doesn't start up correctly or freezes very early.
At the robotics club, we have made many custom STM32 boards in recent years. Here are some pitfalls we noticed: * it is very important to follow STs hardware development guide, e.g. AN2586[0] * you should use all the required capacitors in the right size and as close as possible to the MCU * make sure that your power supply is working correctly and that all ground paths are well routed * make sure you added a capacitor of the correct size to your LDO (see LDO's datasheet) * at least on some STM32 MCUs, the PLL is powered from the analog power in, thus it always needs to be supplied with power, when the PLL is to be used Maybe that helps.
The other thing that happens is that after a while (sometimes minutes, sometimes as low as 5 seconds), when things are already working, the cpu freezes, and when I read the cpu state with ST-LINK it seemed like it was in the hard fault handler. Do you have any suggestions for any of these problems? Like basic wiring of the cpu (I already have BOOT0 on GND, didn't find anything else needed), and tips on how to debug a hard fault (maybe an xpcc-specific solution).
I always use gdb for debugging hard faults. Just connect openocd to your target, start the arm-none-eabi-gdb and when you encounter a hard fault, you can stop the program and use the `where` command to display all stack frames. You can navigate the frames with the `frame` command. The `layout split` command shows the assembly and C++ source, this way you can find the instruction that caused the hard fault. Common reasons are: * trying to access memory location 0 (NULL pointer dereferencing) * accessing unaligned memory locations is not allowed for some instructions `xpcc` has some notes on how to use arm-none-eabi-gdb together with openocd in the repository (see `examples/stm32f3_discovery/gdb`) I hope you can find a solution to your problem. If you need help with deciphering the stack frames or the instruction that causes your hard fault, you can send the gdb output together with the relevant C++ code to the mailing list. If you do so, please change the mail subject, to make it easier for other people to find the mail thread, if they have a similar problem. Good luck! Kevin [0]: http://www.st.com/web/en/resource/technical/document/application_note/CD0016...