STM32 Fatal Error on Sample Blinky and A Simple Counter++ program

[jumper385]

Hi All!

I'm having issues with getting a working blinky on the stm32_min_dev_blue board while following the getting started guide and board files and sample code. Additionally, simpler counter++ programs also fail under this test. I've given this a try on MacOS, Windows and Linux - each with no avail. In each configuration, I have flashed with both, a J-Link (EDU) and ST-Link V3 Mini. I usually have more success with flashing using a J-Link EDU as there are issues with the ST-Link V3 Mini.

Each time I debug the program, the chip follows the following instructions until it hits the infinite fatal.c loop:

Additionally, I've seen this issue on a nucleo_f302, a custom stm32f302c8t6 board and the weact stm32h743 board. This is in contrast with my other nrf52832, nrf52840 and ESP32C3 boards - which really confuses me as each of those use different debug/flashing systems.

To flash, I use west flash --runner jlink. To debug, I use west debug --runner jlink.

Would anybody know what's going on here? Are there missing configurations I should be enabling? or missing libraries? I'm using the default zephyrproject installation on the getting started project AND a custom workspace from the example-application template. Is there a missing installation I've missed?

[erwango]

Strange, it means that you're not able in any way to run a basic zephyr sample on a STM32 based board, while it works on other boards ?
Which SHA1 are you using ?

[jumper385]

Im getting the same issue - this is with the stm32_min_dev_blue. Additionally, I'm running it all on Ubuntu on WSL and using python virtual environments. In eachscreenshot, I'm using a J-Link EDU and an ST-Link V3 Mini.

On your install, would u know what prerequisite installs you've used? Should I install STM32CubeIDE?
at the moment, the installs I've made are

• ST-Link CLI
• gcc-arm-none-eabi
• all other installs specified by the getting started guide

Using a J-Link

Using an ST-Link

Test Setup

[erwango]

I'm running Ubuntu 20.04, flashing with openocd or stm32cubeprogrammer runner.

[jumper385]

Okay... i'll find a way of installing stm32cubeprogrammer on my laptop and try again - would you know what a possible problem is?

[jumper385]

how would you do the setup for stm32? would it be a matter of following the normal installation instructions?

[erwango]

Yes, no specific instalation and you shouldn't face any specific issue. I'm only using ST dev boards though, maybe STM32 boards from other vendors are less tested but I don't see why you would face the same systematic issue on all STM32 boards.

[jumper385]

Yehh... Are there any commands you'd like me to run to check what's going on? I'm stumped on what's missing. Is there any way to compile on a remote device/server that you'd recommend for this instead? Maybe I can compile on a fresh and separate machine? Do you think its a compile issue? or a flashing issue? I can try purchase a nucleo dev board and see what to do again but it'll just take a while... I'm a bit unsure whats going on though - i'm still able to flash using stm32cubeide and the stm32 development environment...

…

On Tue, 17 Oct 2023 at 16:24, Erwan Gouriou ***@***.***> wrote: Yes, no specific instalation and you shouldn't face any specific issue. I'm only using ST dev boards though, maybe STM32 boards from other vendors are less tested but I don't see why you would face the same systematic issue on all STM32 boards. — Reply to this email directly, view it on GitHub <#63946 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEB74Q7XAYMJOBUQTS7Y52DX7Y6CNAVCNFSM6AAAAAA6ADXKA6VHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TGMBRGI2DE> . You are receiving this because you authored the thread.Message ID: ***@***.*** com>

[erwango]

You can have a try using a Cube build fw on your boards.
Honestly, if you're able to flash, I don't understand how you could get to such issue.

[fpistm]

Hi @jumper385
About STLink, is it a legacy one? You could try to update the STLink Firmware, you can do this with STM32CubeProgrammer pressing the "Firmware upgrade" button:

About the Blue Pill, is it a guenine STM32F103? There is a lot of clone/fake which can explain some of your issue. Also, on your picture it seems the Boot mode configuration is not correct. Boot 0 and 1 jumpers should be set to LOW (0). Finally, did you try to power it thanks USB instead of 3.3V pin of the connector? Pay attention to not have USB and 3.3V at the same time.

[jumper385]

Hi All!

I've just received a new nucleo board and its works on the nucleo_f042k6.

I was also testing on a custom stm32f103c8t6 board that i had lying around and noticed it had a timing issue - but the blinky works.
The clock on that was a 16 MHz crystal i probed - and it had 16MHz. When i use the external clock clk_hse as the clock source for the pll however, it doesnt work. Using the internal clock worked. This will be down to my implementation so i'll take more time to figure out whats going on here.

I probed the crystal on the stm32 bluepill and the crystal output didnt seem to ahve anything - i suspect it would have died like that. Interestingly, switching to the internal clk_hsi didnt work either so i'm a bit stumped. My other boards I'm yet to test.
Thankyou all for the help. If i find any more issues regarding clocks doing this i'll be sure to chuck them up on this thread.

Kind Regards,
Henry