STM32F410 Loads code ok, even I can see the registers and PC moving with the Cube Software, but won't even blink a LED

[rhormigo]

Hi,
I am new here and to the STM32 world, I did worked several other CPUs in the past, now mostly AVR, and Teensy. But here I have the need of a very simple, small, and fast deterministic solution to create a one shot programmable in length pulse, that is synchronized externally. Essentially some small with lots of mips and light running (no IRQs or other disruptions in the background) Teensy is problematic at that. I saw the STM32 families simplicity, performance, and low cost, on top of STM32duino and got in love, and wrote some very quick for these STM32F103s available everywhere for 10 bucks including debugger! Timing was shockingly great, not a lot of jitter and I can sync a pulse with in 100nS (pulse length down to 32nS writing directly the IO registers).

Now, I found that the STM32103F103C8/B family can be hard to get stock individually (at least now) and also has USB that I don't use at all, in fact I have to deactivate all IRQ background to maintain timing right. So I found lying around a shield board to control stepper motors with a STM32F410 and found is a great match, very small , simple, and at 125MIPS even significantly faster than the STM32F103. Schematic here:



However, not sure what is going on in this board, as a simple blink a led connected to PC13 doesn't work with this particular CPU, it loads successfully only but even if it says is running, doesn't appear so. The same code in the STM32F103 is ok . I loaded this using the generic variance for STM32F410CB and no errors are reported. I tried both with ST link and UART methods and same results. With the ST link I can go to the Cube programmer and see registers, memory loaded, etc. Even i can stop and step on the CPU core but still won't work. The CPU board is fine because I saved the original stepper shield code in the CPU to a bin file and put it back and that interact with the same LED fine. Is the code that comes from STM32Duino what doesn't interact with the world.

I also compiled in the Arduino IDE to export compiled bin file and then program with CUBE and same results.

My only leads at this time are the fact that there is no 32K oscillator installed, and the main one is 24MHz that depending how the clocks are configured by default in the programmer may result in a non clock situation?
Also could the linker or programmer have watchdog enabled by default?
I know are long shots but also I am not familiar yet of how the STM32duino or the Cube programmer set the clocks or watchdogs before any code is read. In the AVR family, the AVR studio programming tool let's you to set all this with their "fuses" menu. No idea how this is done in ST world yet.

I saw here some posts with a similar issue on a STM32F401 that I also have ordered to evaluate. But answers suggest initialization settings on the hal, clocks , etc. All that I imagine assumes there is a valid clock running code already. I am not even sure my code is moving at all.

Any suggestions? Otherwise can suggest an least painful path to program and ICD directly ST32F. ST tools to took at?


Thank you, and sorry for the lengthy email, have been two long days already.

[rhormigo]

Just an update, it looks like updating the HSE frequency #define to 24MHZ makes the code at least working
From:
#define HSE_VALUE 8000000U
To:
#define HSE_VALUE 24000000U

What I didn't expect as the function SystemClock_Config() at the file variant.cpp suggest to sequence to the next available clock source if that fails until I imagine come back to the internal default. What is not consistent with the clock apparently gone. I am guessing the default 8MHz setting makes all hell lose when feed with 24MHz, but still the function returns OK.

Now I need to figure out, why delay() and delayMicroseconds() are twice faster than as called. The UART works fine at the programmed bauds however.
I probably will do a new post about that.

RH.

[fpiSTM]

Hi,

generic variant provide a default system core clock config based on the default HSE_VALUE.
For F4 it is 8MHz so if your board as a 24 MHZ HSE then the software could not know that you have to specify it by:
1- Redefine the HSE_VALUE using build_opt.h or hal_conf_extra.h: https://github.com/stm32duino/wiki/wiki ... figuration
2- Create your own SystemClock_Config:
https://github.com/stm32duino/wiki/wiki ... ock_config

[ag123]

There was some stories about the blue pill led in the old forums, that the color of the led is different between the peces, and the most fun goof is the led placed reverse biased

[darkspr1te]

I have recently developed a bootloader for the stm32f4xx series and I can say that clocks and setup varies in each build environment, some set them up fully and others require input and without such input will default to values that can cause issues later on.

Heres some tips I have learned along the way
1. Use stm32cube to create a basic project with the clock selector page it's really easy to input correct values and visualize your pll multipliers.

2. use ghidra32 to disassemble your project to confirm your compiled code includes all of your code (i chased a bug for weeks to find the build environment was using it's own systemclock_init() function and not mine )

3. use makefile export function of stm32cube if you wish to use in atom/platformio/linux/wlss as it makes for speedy one line compile option without loading a entire ide project for and make easy importing in a lot of ide's
4. always use a debugger , you can freeze the system and inspect registers.

of course these tips only help if you are using stm libs, if your using other core libs like libcm3 and such then they wont apply directly.

darkspr1te

[noweare]

I would think using CubeMX for setting everything up and looking at registers would expose the problem.
Are you sure the led your trying to blink is working?

[fpiSTM]

Hi,
Just think about this issue:
https://github.com/STMicroelectronics/S ... /issues/17

I've saw some strange behaviour linked to this issue.