Fairly new to STM32 development, but I’m working on playing a simple 440Hz sin tone out of the STM32407’s on-board audio codec with I2C. When I upload the program using the Keil IDE after configuring with CubeMX, I get a 440Hz tone. But when I move all the files to Platform IO and upload using PIO’s STM32 library, I get a much lower sin tone.
platform = ststm32
board = disco_f407vg
framework = stm32cube
upload_protocol = stlink
; extra_scripts = extra_script.py
debug_tool = stlink
Are there any differences in the ways that PIO and the Keil IDE flash code onto the discovery that would somehow affect sampling rate or clock speeds?
Many thanks to anyone who can help out
Hard to say without the full code; could be anything.
There’s too much src to put in the comments so I zipped it up and put it above on google drive, hope this helps and lmk if there’s anything else I can put up!
You can ignore the
lib directory too, nothing is being called from there
Hm I don’t see anything really wrong with the code.
Note that the
src\stm32f4xx_hal_conf.h will not be used when compiling the STM32Cube framework size since PlatformIO generates a default one. If you want your file to be used, move that file to
include/ and follow Stm32cube stm32XXX_hal_conf.h / Include search path - #3 by Rainer1 (but for the
framework-stm32cubef4 / F4 series ofc).
But the code is pretty simple so tracing it should give some insights.
First, there could be a difference in math libraries. In PlatformIO (Unified debugger) and Keil you should be able to place a breakpoint in
main.c:133 to inspect the contents of the
dataI2S array (or, the first 218 elements of it). What are the contents of those arrays for the PlatformIO and Keil version respectively?
(You may also be able to just print them via UART /
Another thing to check would be if the Keil version behaves the same when you activate code optimizations. I’ve seen cases here where a difference in behavior was caused by Keil using no compiler optimization level or not optimizing something at all.
If that also reveals nothing, the I2C transfers to the audio codec should be checked, by e.g. adding printf()s into
If that also doesn’t reveal anything (sent I2C configuration is identical, values in array which are supposed to be transmitted via I2S are identical), then one must take a logic analyzer and see what actual values are sent via I2S there, electrically, with a logic analyzer.
Seems as though I solved my issue! I changed the framework in
cmsis instead of
stm32cube and with the addition of some STM32 drivers in my project path, I get my 440Hz sin tone…
Still going to try out some of those debugging techniques and circle back to see what specifically it was causing the problem. Your help is much appreciated, thanks again
Just for kicks, is there any way to load both the stm32cube framework and the cmsis layer so that I don’t have to externally add all the
stm32f4xx_hal_* library files manually to my project?