Not during the first test. I tried it now and it doesn’t change anything.
How can I know if I use the HSE clock setup? As I told you, I reverted variant.cpp to the original version which seems to use HSE.
I connected both USB-OTG #1 and #2 and no serial interface showed up on my computer.
Best to remove any SystemClock_Config() from your main firmware and modify the variant.cpp to use the function I posted above STM32-E407 doesn’t work on PIO - #3 by maxgerhardt (second code listing)
Now it works on USB-OTG#1. I added your SystemClock_Config() in my project and it works. Some things remain though:
extern "C" stuff so I did not use it and it works like that..h file without .c file as I didn’t find a way to make it work.I pushed the code to my depot on GitHub if you want to have a look.
Actually I was wrong about it, the function is defined in a .cpp file and not a .c file as I originally thought
./variants/BLACK_F407XX/variant.cpp:WEAK void SystemClock_Config(void)
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.
All these boards have an extra USB-Serial converter chip which is always on and is not affected by a press of the reset button. Used converter chips are e.g. the CH340G or a Silabs CP2104.
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.
