I’m playing around setting the STM32F4 and STM32L ‘Discovery’ evaluation boards from ST, with gcc and OpenOCD on Ubuntu. ST only offer setups for costly toolchains, and I wouldn’t want to go there would I. After reading manuals and building makefiles I got most of the examples running, but had a couple of problems with OpenOCD.
These boards use an STLINK device to connect to the chip via the SWD interface.
My STM32L has a 256k STM32L152RC chip. OpenOCD can’t read the flash size and says it’s 10k. This turns out to be because ST moved the flash size parameter on the larger chips from 0x1ff8004c to 0x1ff800cc. This affects the C and D suffix devices, device id 427 and 436. Overriding the size in the script works OK for a specific chip type, applying a simple fix to src/flash/nor/stm32lx.c and re-making solved the problem completely, and means I can use the supplied board/stm32ldiscovery.cfg script.
On both devices I find problems if the debugger tries to talk to the chip while the CPU is running. With the STM32L openOCD fails to initialise about half the time due to misreading the chip data, assuming the board powered up in a running state. Holding down the board’s reset button while initialising openOCD usually works.
With the STM32F4, initialisation is OK, but if I don’t halt the CPU before loading a program (via gdb) then I sometimes get occasional odd byte errors in the program, which appear random (and are horrid to debug) but are repeatable for the same program. Comparing the flash contents with a hex binary load file shows differences. Ensuing the CPU is halted before loading appears to eliminate this problem.
Tim Jackson