Hello, I am working with the STM32 discovery board that has the STM32F407VG processor. Currently this is programmed in mbed using Seeed Arch Max target, even though Seeed Arch Max’s target is STM32F407xE it works with the xG of the discovery.
The custom PCB we are trying to program using the ST LINK SWD of the same discovery board has a STM32F407ZGT processor. The problem is that mbed gets stuck on Run Program after compiling and erasing. The only difference between ZG and VG is flash memory size, GPIO pin count and ADC pin count.
- Uploading to custom PCB using STM32CubeProgrammer with Cube generated elf file works.
- Uploading to custom PCB works with Cube IDE and Cube generated code works.
- Uploading to custom PCB with STM32CubeProgrammer with mbed generated elf uploads, but does not run.
- Uploading to PCB with mbed debugger results GDB server does not start.
- All of the above works on the discovery board.
So mainly I’m confused why the Seeed target works with the discovery board and not with our custom PCB.
***Update: Switched programmer to a STLINK V2 module and can now program from mbed but the code still does not run. When uploading from CubeIDE the program runs still.
Is it possible there’s any difference in oscillator configuration between your custom board and the Arch Max? Like, different high speed oscillator frequency, or lack of an RTC crystal?
Apologies for the late reply, lots of testing since the last post. To update, you are correct that it is something to do with the clocks. We are able to upload and run code using mbed only if using HSI and no PLL. So our clocks running at 16MHz for SYSCLK, APB1, APB2, and AHB. Using this config we know the chip is running by testing the PWM outputs and UART outputs. As soon as PLL is enabled to multiple clock frequency higher, we get no output on these peripherals so assume chip is not running (using prescaler of at least DIV4 so bus speeds are not exceeded). At this point we are pretty sure our external oscillator is fine then, as when enabling PLL on HSI it still freezes the chip. Worthy to note we test by copying the system clock config directly from the generated code of STM32Cube into mbed for these clock configs.
Possibly related or unrelated issue, when running at 16MHz no PLL so we have peripheral outputs, our UART transmission has a frame error. When developing on discovery boards we had a similar issue that was fixed by adding bias resistors to the RS485 modules were using. On this PCB we have a via before the RS485 module that can be tested for UART3 and header for UART2 both of which produce a frame error. On discovery boards we used a baud rate of 2.5M on UART3 for the RS485 modules, which doesn’t output when running on 16MHz sys clock. Found that only 1M outputs but still, with frame errors. I’ve attached the logic output for the frame errors expected packet: “#9900000000000000000000000999#”.
Any additional insight is appreciated and can provide more information as well.
If you use STM32Cube, are you able to use the PLL there? Or does turning on the PLL always freeze the chip no matter what you use to program it?
“chip freezing when you turn on the PLL” sounds to me like maybe you have bad PLL settings, I’ve seen that before. What if you use STM32CubeIDE to generate a new SetSystemClock function and replace the one in Mbed?
Fixed, found that mbed does the clock initialize from within the target. Found in “mbed-os/targets/TARGET_STM/TARGET_STM32F4/TARGET_STM32F407xE/system_clock.c” just changed to select external crystal and do no other clock setup in main.cpp. Clock setup is done from there when calling HAL_Init(). Going to test the UART tomorrow to see if the same frame error persists now that we are at 168MHz. Thanks for the feedback.
