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/CD00164185.pdf
_______________________________________________
xpcc-dev mailing list
xpcc-dev@lists.rwth-aachen.de
http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev
