Hi @ouilogique! Could you please try to update the platform to v5.6.0 and run your Arduino example again? We’ve added a workaround for boards with core coupled memory so BLACK_F407XX variant should work now. Thanks!
This is good, it suggests that HSI works without problems. However this means that the reason the Arduino framework is not working is only partly becaue of wrong clock and there is something else. Out of curiosity, what if you replace SystemClock_Config() again with the HSE startup routine from the beginning of the thread in the STM32Cube example?
valoros’s answer suggest that it might work now for Arduino after a platform update (either in the vscode update GUI or pio platform update). If not, you need breakpoints at strategic breakpoints during the bootup to see where it goes wrong. Like <user>\.platformio\packages\framework-arduinoststm32\system\STM32F4xx\system_stm32f4xx.cSystemInit(),SystemCoreClockUpdate() or SystemClock_Config() from the variant folder, main() function etc. Also, this define might help?
After upgrading the STM32 platform to version 5.6.0, the LEDs are blinking but the serial communication does not seem to work. I connected an UART dongle to the TX and GND pins of the UEXT connector and also on the same pins of the BOOT headers, but there are no messages.
The UEXT connector has PC6 (TX) and PC7 (RX) which belong to USART6. PA9 in the board is unfortunately also OTG_FS_VBUS so its shorted to the VBUS connection of the USB_OTG1 connector. (see above schematics page 27). I’d say it’s the easiest to just enable the serial object for USART6 and use it. (Or, actually create a proper variant for the board in the arduino framework…)
Yes! Now my Hello World example works completely! Many thanks to you maxgerhardt and valeros!
I have updated my git depot of this project to reflect what was said in this thread. Unfortunately, my posts with links are labeled “This post was flagged by the community and is temporarily hidden.” Is it possible for you to unflag my first post or to post the URL to my git depot so that people interested in this topic can see the link?
One last question: I can read the serial output on the UEXT connector and on the BOOT header (beside the UEXT connector). Is it possible to read the serial output on USB-OTG 1 or 2?
If you haven’t done it already, another improvement would be to move the SystemClock_Config() from the framework-arduinostm32 folder (which might be overwritten by updates) into the actual main firmware. This should work because the function is marked _WEAK in the framework, meaning it should be possible to be overwritten by simply pasting the correct SystemClock_Config() in the main.cpp but adding extern "C" in front of the void .. (to get C name linkage because the original function was defined in a .c file, not .cpp file). Worth a try.
A wrongly approved spam flag for Olimex links has been reverted now.
You mean you want the device to be a USB CDC (aka virtual COM port) by using its USB peripheral? Yeah Arduino STM32 has SerialUSB support, needs to be activated via some build flags.
Take a look at Difficulty with getting USB serial [USB CDC] working - #6 by maxgerhardt and try to incorporate the build flags with the current ones. Important: You probably need to remove PIO_FRAMEWORK_ARDUINO_SERIAL_WITHOUT_GENERIC and also need a working SystemClock_Config()from HSE! The internal HSI will not work for USB because it is too inaccurate, this needs the HSE. (see ST Community). I don’t know which connector it will choose though without further looking into it.
Yes, it is great that it works. At the beginning my idea was only to test the board quickly. I thought the Arduino framework would help to go fast, but I was wrong. I need to learn STM32Cube for my job, but the learning curve is quite steep so I decided to test the board with the Arduino framework first…
For the SystemClock_Config(), I can do as you said, but I really wonder if this is necessary as it works with the original variant.cpp file. I tried it on a fresh install of PlatformIO and it works. Moreover you say that for USB CDC to work, HSE is needed and it is the case in the original variant.cpp file.
I tried to activate USB CDC on my board, but it doesn’t work. The compilation and upload work OK, but no new serial interface is shown on my computer. Here is my platformio.ini:
So not adding extern “C” (explanation) is actually correct.
This is weird but still correct if the header file is only included once by one .cpp file. If the header file is not included then the function is also not compiled. However, adding this function directly to main.cpp should also work. What error did it throw?
This is expected since on reset, the MCU stops the USB peripheral, your computer gets a disconnect for that USB device, the serial monitor gets a “closed port” error. There is no way known to me which prevents this from happening on a power cycle. You’d have to disconnect and reconnect the serial monitor before and after the reset. That’s why hardware UART ports are kinda neet.
OK, so after a break I found what I did wrong when trying to split SystemClock_Config(void) in .c and .h files: I simply forgot to include Arduino.h in System_Clock_Configuration.c.
I really prefer not to include the function directly in main.cpp to keep this example as close as possible to a real dead simple “Hello World” example.
For the disconnection of the serial connection through USB-OTG#1, your explanation makes sense. Now what I don’t understand is that the exact same functionality works on all other boards I used so far (Arduino UNO, ESP8266, ESP32…). If you have an idea of what is different between the E407 board and the other boards, it could be interesting to know.
The CH340G is always connected to D+/D- and power, and its RXD and TXD pins are connected to the ATMega328P. When the ATMega328P resets, nothing happens to the serial converter chip, the connection stays.
You would have a “USB disconnect on reset” behaviour on e.g. the Arduino Pro Micro (ATMega32U4) because it has the USB peripheral on chip, which gets reset when the chip resets.
If you would slap a USB serial bridge unto the UART ports of UEXT or BOOT which is permantely powered, you would get the wanted behaviour of a never-disconnecting serial bridge.
Well thank you for your explanation, it totally makes sense now.
I also thank you and valeros too for your support. Without your help I couldn’t have made this example work.
As I told you, the idea was to discover the board quickly before diving into STM32Cube framework which seems not to be a piece of cake… I also have hard times to make my ARM-USB-OCD-H programmer work. So we will probably meet again in this forum.