Page 3 of 5
Re: WeAct Studio STM32F411CEU6 BlackPill v3.1 crystal is 8 MHz
Posted: Sun Apr 21, 2024 2:48 am
by Fziegler_076
void SystemClock_Config() {
return; // <- return on entry, so no clock setting is done
....
}
Should I do this in a sketch or fix some file?
I also bought the same boards with HSE 25 MHz today, but they will arrive no earlier than in 2 weeks.
Re: WeAct Studio STM32F411CEU6 BlackPill v3.1 crystal is 8 MHz
Posted: Sun Apr 21, 2024 2:53 am
by ag123
for 32k RTC crystal , i've a few times it doesn't oscillate, but normally for the HSE 8, 12, 25 mhz crystals etc, seldom have problem, so it is surprising if HSE don't oscillate, but maybe sometimes that can happen.
Re: WeAct Studio STM32F411CEU6 BlackPill v3.1 crystal is 8 MHz
Posted: Sun Apr 21, 2024 2:55 am
by ag123
Fziegler_076 wrote: ↑Sun Apr 21, 2024 2:48 am
void SystemClock_Config() {
return; // <- return on entry, so no clock setting is done
....
}
Should I do this in a sketch or fix some file?
I also bought the same boards with HSE 25 MHz today, but they will arrive no earlier than in 2 weeks.
inside that variant file
Re: WeAct Studio STM32F411CEU6 BlackPill v3.1 crystal is 8 MHz
Posted: Sun Apr 21, 2024 3:05 am
by Fziegler_076
oid SystemClock_Config() {
return; // <- return on entry, so no clock setting is done
I have corrected the file
Code: Select all
oid SystemClock_Config() {
return; // <- return on entry, so no clock setting is done
Unfortunately, this doesn't work either (
I will try it via ST-LINK
Re: WeAct Studio STM32F411CEU6 BlackPill v3.1 crystal is 8 MHz
Posted: Sun Apr 21, 2024 3:27 am
by ag123
if that doesn't work, then it is unlikely to be a clock issue, because by returning in void SystemClock_Config(), before clock setting.
it is running on its internal clock, not even on the crystal
it seem you have a few boards, all of them don't work?
Re: WeAct Studio STM32F411CEU6 BlackPill v3.1 crystal is 8 MHz
Posted: Sun Apr 21, 2024 3:33 am
by Fziegler_076
if that doesn't work, then it is unlikely to be a clock issue, because by returning in void SystemClock_Config(), before clock setting.
it is running on its internal clock, not even on the crystal
it seem you have a few boards, all of them don't work?
Yes, I have 10 boards! I've already checked on 4x and it doesn't no work on all 4x via USB DFU
I understand you!
Thank you very much!
I will be able to test with ST-Link only tomorrow and I will write immediately
Re: WeAct Studio STM32F411CEU6 BlackPill v3.1 crystal is 8 MHz
Posted: Sun Apr 21, 2024 3:41 am
by ag123
if the stm32cube programmer messages make sense, it seem your boards are actually working, otherwise cannot even program.
but the blink test not working is unusual.
I rebuild a blink test with some other test usb, adc, temperature reading, whetstone benchmark etc
my board is 25 mhz, I've rebuild this for hse 8 mhz fcpu 84 mhz
you can try flashing and testing
but this is for stm32f401 not f411
this one has virtual comm port, you can try using putty to connect
https://www.putty.org/
i think arduino ide serial monitor works as well
edit:
I uploaded a new bin file, should be the same but if it works the statistics for this is more accurate, previous one I define wrong fcpu to calculate wheatstone benchmark
Re: WeAct Studio STM32F411CEU6 BlackPill v3.1 crystal is 8 MHz
Posted: Sun Apr 21, 2024 3:49 am
by Fziegler_076
Yes, the programming of the boards is fine, but the LED does not really work.
On another STM32H7 board
https://aliexpress.com/item/1005005872938104.html
everything is fine being flashed through DFU and the LED is working fine!
Re: WeAct Studio STM32F411CEU6 BlackPill v3.1 crystal is 8 MHz
Posted: Sun Apr 21, 2024 5:49 am
by fpiSTM
Try to debug using Arduino IDE 2.2.1.
The latest version 2.3.x changes the debug configuration way. I will fix this within next release.
Simply enable the optimize for debugging option and you should be able to debug and see where it stucks.
Re: WeAct Studio STM32F411CEU6 BlackPill v3.1 crystal is 8 MHz
Posted: Sun Apr 21, 2024 8:27 am
by Fziegler_076
Try to debug using Arduino IDE 2.2.1.
The latest version 2.3.x changes the debug configuration way. I will fix this within next release.
Simply enable the optimize for debugging option and you should be able to debug and see where it stucks.
Thanks!
I'll try it tomorrow.