STM32duino + STM32F405RG on VESC bldc controller

Development Platforms
1

Hello,

I’m trying to run Arduino code on a VESC 4.12 which uses an STM32F405RG. I am using the genericSTM32F405RG board option. Here is the hardware schematic: https://github.com/vedderb/bldc-hardware/blob/master/design/BLDC_4.pdf?raw=true I am using an ST-Link v2 for uploading and debugging.

I haven’t been able to achieve anything that demonstrates my code is running, though it uploads without error. A blink program using either PC4 or PC5, where LEDs are connected, does not blink LEDs, and running with the PIO_FRAMEWORK_ARDUINO_ENABLE_CDC build flag does not cause USB to enumerate. When I try to debug either one of two issues occur. 1) the program seems to start running and then stops on one instruction and PC doesn’t seem to increment, or 2) I get the error “openocd: /Host/home/ilg/Work/openocd-0.10.0-13/openocd.git/src/flash/nor/stm32f2x.c:1205: stm32x_probe: Assertion `(bank->size >> 10) == flash_size_in_kb’ failed.” when it tries to launch the debugging session. I’m not sure why stm32f2x.c is being used as the project is for an f4x. I’m not sure why that assertion fails sometimes and not others. Here is the full output from the debug console:

Processing genericSTM32F405RG (platform: ststm32; board: genericSTM32F405RG; framework: arduino)
--------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/ststm32/genericSTM32F405RG.html
PLATFORM: ST STM32 7.0.0 > STM32F405RG (128k RAM. 1024k Flash)
HARDWARE: STM32F405RG 168MHz, 128KB RAM, 1MB Flash
DEBUG: Current (stlink) External (blackmagic, jlink, stlink)
PACKAGES:
 - framework-arduinoststm32 4.10900.200602 (1.9.0)
 - framework-cmsis 2.50501.200527 (5.5.1)
 - toolchain-gccarmnoneeabi 1.90201.191206 (9.2.1)
LDF: Library Dependency Finder -> http://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 15 compatible libraries
Scanning dependencies...
No dependencies
Building in debug mode
Checking size .pio/build/genericSTM32F405RG/firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [          ]   0.7% (used 856 bytes from 131072 bytes)
Flash: [          ]   0.8% (used 8820 bytes from 1048576 bytes)
========================= [SUCCESS] Took 3.61 seconds =========================
Reading symbols from /home/levi/Documents/PlatformIO/Projects/vesc_test/.pio/build/genericSTM32F405RG/firmware.elf...
PlatformIO Unified Debugger -> http://bit.ly/pio-debug
PlatformIO: debug_tool = stlink
PlatformIO: Initializing remote target...
xPack OpenOCD, 64-bit Open On-Chip Debugger 0.10.0+dev (2019-07-17-11:25)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
hla_swd
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : tcl server disabled
Info : telnet server disabled
Info : clock speed 2000 kHz
Info : STLINK V2J37S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.163636
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'gdb' connection from pipe
Info : device id = 0x10076413
Info : flash size = 8194 kbytes
openocd: /Host/home/ilg/Work/openocd-0.10.0-13/openocd.git/src/flash/nor/stm32f2x.c:1205: stm32x_probe: Assertion `(bank->size >> 10) == flash_size_in_kb' failed.
Aborted (core dumped)
.pioinit:13: Error in sourced command file:
Remote connection closed

Here is my platformio.ini:

[env:genericSTM32F405RG]
platform = ststm32
board = genericSTM32F405RG
framework = arduino
upload_protocol = stlink
debug_tool = stlink

I updated the firmware on my ST-Link. Any ideas what the issue is? Any help is appreciated. Thanks.

2

…8 Megabytes of flash on a STM32F405RG? Did your chip accidentally get some steroids during manifacture? :smiley: The chip is supposed to have a maximum of 1 Megabyte.

Can you download and use the official STMicroelectronics tool STSW-LINK004 - STM32 ST-LINK utility - STMicroelectronics to try and connect to chip via the Software System Reset method in the settings? Can you show a screenshot of when the tool connects, and especially its flash size?

If you are on Linux, use stlink and do a st-info --probe.

2 Likes
3

You also need additional flags here: Difficulty with getting USB serial [USB CDC] working - #6 by maxgerhardt

But before getting USB to work you should focus on the LED blinking. If that doesn’t work it means that the controller maybe doesn’t even reach the setup() or loop() methods. Maybe stuck in clock initialization or crashing.

Can you show the code you’re using for the blink? Did you try using digitalWriteFast(PC_4, HIGH); too? Or just digtalWrite(PC4)? (Mind, one is a PinName enum, the other a integer behind a mapping)

1 Like
4

Thanks for the quick response! Yeah, that definitely seems like an issue :sweat_smile:. Not sure why I didn’t catch that. I’ll post the output of the stlink tool tomorrow. Here’s the code I tried (using just digitalWrite):

#include <Arduino.h>

void setup() {
  pinMode(PC4, OUTPUT);
}

void loop() {
  delay(250);
  digitalWrite(PC4, HIGH);
  delay(250);
  digitalWrite(PC4, LOW);
}

Also thanks for the info on the flags required for USB. I’ll keep that in mind.

I’ll post the output of stlink tomorrow. Thanks again.

5

Here is the result of st-info --probe:

Found 1 stlink programmers
 serial:     252611002c135737334d4e00
 hla-serial: "\x25\x26\x11\x00\x2c\x13\x57\x37\x33\x4d\x4e\x00"
 flash:      1048576 (pagesize: 16384)
 sram:       196608
 chipid:     0x0413
 descr:      F4xx

The flash size appears correct in this case. I tried debugging with PlatformIO again as a sanity check and got the same 8194 KB as before. Any idea what could be causing this?

6

Okay so it seems you’re using Linux. It’s indeed weird that debugging never works…

3.16V at a target of 3.3V seems a bit low – is the target board externally powered from a good power source and cable?

When attempting to debug, does it always fail after reading the wrong flash size?

If st-util and friends can read the flash size correctly, maybe you can use it as a debugging server like in
PIO unified debugger and sublimetext - #2 by krishna_chaitanya. For that, remove the old debug_tool = stlink and add

debug_tool = custom
debug_port = :4242
debug_server = <path to st-util binary>

It should also open a GDB server.

If there are problems with that, please post the output of running st-util alone or any other occuring error.

1 Like
7

Yeah, 3.16 does seem a bit low. This was using the 3.3V supply on the ST-Link. I’ve also tried using the 5V supply from the ST-Link to the 3.3V regulator on the board, and I’ve tried using a 4 cell LiPo (how the board was designed to be powered) which goes through a 5V regulator to the 3.3V regulator. In each case, the voltage was 3.16-3.17V as output in the debug console. Using a voltmeter, the 3.3 volt line is at about 3.27 resting.

Occasionally, it will make it past that assert and instead issue a warning: Warn : STM32 flash size failed, probe inaccurate - assuming 1024k flash. Here is the debug console output in this case:

Processing genericSTM32F405RG (platform: ststm32; board: genericSTM32F405RG; framework: arduino)
--------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/ststm32/genericSTM32F405RG.html
PLATFORM: ST STM32 7.0.0 > STM32F405RG (128k RAM. 1024k Flash)
HARDWARE: STM32F405RG 168MHz, 128KB RAM, 1MB Flash
DEBUG: Current (stlink) External (blackmagic, jlink, stlink)
PACKAGES:
 - framework-arduinoststm32 4.10900.200602 (1.9.0)
 - framework-cmsis 2.50501.200527 (5.5.1)
 - toolchain-gccarmnoneeabi 1.90201.191206 (9.2.1)
LDF: Library Dependency Finder -> http://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 15 compatible libraries
Scanning dependencies...
No dependencies
Building in debug mode
Checking size .pio/build/genericSTM32F405RG/firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [          ]   0.7% (used 952 bytes from 131072 bytes)
Flash: [          ]   1.3% (used 13824 bytes from 1048576 bytes)
========================= [SUCCESS] Took 3.35 seconds =========================
Reading symbols from /home/levi/Documents/PlatformIO/Projects/vesc_test/.pio/build/genericSTM32F405RG/firmware.elf...
PlatformIO Unified Debugger -> http://bit.ly/pio-debug
PlatformIO: debug_tool = stlink
PlatformIO: Initializing remote target...
xPack OpenOCD, 64-bit Open On-Chip Debugger 0.10.0+dev (2019-07-17-11:25)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
hla_swd
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : tcl server disabled
Info : telnet server disabled
Info : clock speed 2000 kHz
Info : STLINK V2J37S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.177575
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'gdb' connection from pipe
target halted due to debug-request, current mode: Handler HardFault
xPSR: 0x80000003 pc: 00000000 msp: 0x2001ff48
Info : device id = 0x10076413
Warn : STM32 flash size failed, probe inaccurate - assuming 1024k flash
Info : flash size = 1024 kbytes
Info : flash size = 512 bytes
0x00000000 in ?? ()
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x080009c4 msp: 0x20020000
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
Loading section .isr_vector, size 0x188 lma 0x8000000
Loading section .text, size 0x2fdc lma 0x8000188
Loading section .rodata, size 0x58c lma 0x8003164
Loading section .ARM, size 0x8 lma 0x80036f0
Loading section .init_array, size 0x14 lma 0x80036f8
Loading section .fini_array, size 0x8 lma 0x800370c
Loading section .data, size 0x98 lma 0x8003714
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08000c10 msp: 0x20020000
Start address 0x8000c10, load size 14252
Transfer rate: 19 KB/sec, 2036 bytes/write.
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Unable to match requested speed 2000 kHz, using 1800 kHz
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08000c10 msp: 0x20020000
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08000c10 msp: 0x20020000
Temporary breakpoint 1 at 0x8000bee: file /home/levi/.platformio/packages/framework-arduinoststm32/cores/arduino/main.cpp, line 50.
PlatformIO: Initialization completed
PlatformIO: Resume the execution to `debug_init_break = tbreak main`
PlatformIO: More configuration options -> http://bit.ly/pio-debug
Note: automatically using hardware breakpoints for read-only addresses.

Program
 received signal SIGINT, Interrupt.
0x3d08b988 in ?? ()

I then paused it and it stopped on a branch instruction 0x08001516: f6 f3 d3 f0 bl 0x87f76c0 (corresponding to line 674 in stm32f4xx_hal_rcc.c if ((HAL_GetTick() - tickstart) > CLOCKSWITCH_TIMEOUT_VALUE) ) and when stepping, it stayed on the same instruction.

Info : halted: PC: 0x3d08b988
halted: PC: 0x3d08b988
Info : halted: PC: 0x3d08b988
halted: PC: 0x3d08b988
Info : halted: PC: 0x3d08b988
halted: PC: 0x3d08b988
Info : halted: PC: 0x3d08b988
halted: PC: 0x3d08b988
Info : halted: PC: 0x3d08b988
halted: PC: 0x3d08b988

The fact that the issue is inconsistent does make me think it is some how power/hardware related. Maybe a bad ST-Link? But how does st-info retrieve the correct flash size? I tried using a debugging server previously, but I don’t think I set it up correctly. I’ll try that and let you know how it goes. But there still seems to be some other underlying issue as I can’t seem to get a blink program to work… Maybe I’ll try configuring it for some other F405 based board (STM32F4Stamp or Adafruit Feather STM32F405) and see if that makes a difference.

Edit: Another thought. When it says Unable to match requested speed 2000 kHz, using 1800 kHz, is it referring to the SWD speed? That seems a bit fast for some jumper cables.

8

2MHz could indeed be a little bit fast. Can you temporarily change all 3 adapter_khz X commands in ~/.platformio/packages/tool-openocd/scripts/target/stm32f4x.cfg from 2000/8000 to something like 250 or lower?

It will auto-adjust to the next actually usuable value (there are steps involved in the SWD speed that the STLink can handle)

9

I tried with the debugging server, and still had the issue of the flash size being incorrect.

st-util
undefined2020-07-01T13:22:49 INFO common.c: F4xx: 192 KiB SRAM, 8194 KiB flash in at least 16 KiB pages.

Full output:

Processing genericSTM32F405RG (platform: ststm32; board: genericSTM32F405RG; framework: arduino)
--------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/ststm32/genericSTM32F405RG.html
PLATFORM: ST STM32 7.0.0 > STM32F405RG (128k RAM. 1024k Flash)
HARDWARE: STM32F405RG 168MHz, 128KB RAM, 1MB Flash
DEBUG: Current (custom) External (blackmagic, jlink, stlink)
PACKAGES:
 - framework-arduinoststm32 4.10900.200602 (1.9.0)
 - framework-cmsis 2.50501.200527 (5.5.1)
 - toolchain-gccarmnoneeabi 1.90201.191206 (9.2.1)
LDF: Library Dependency Finder -> http://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 15 compatible libraries
Scanning dependencies...
No dependencies
Building in debug mode
Checking size .pio/build/genericSTM32F405RG/firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [          ]   0.7% (used 952 bytes from 131072 bytes)
Flash: [          ]   1.3% (used 13824 bytes from 1048576 bytes)
========================= [SUCCESS] Took 3.29 seconds =========================
st-util
undefined2020-07-01T13:22:49 INFO common.c: F4xx: 192 KiB SRAM, 8194 KiB flash in at least 16 KiB pages.
2020-07-01T13:22:49 INFO gdb-server.c: Listening at *:4242...
Reading symbols from /home/levi/Documents/PlatformIO/Projects/vesc_test/.pio/build/genericSTM32F405RG/firmware.elf...
PlatformIO Unified Debugger -> http://bit.ly/pio-debug
PlatformIO: debug_tool = custom
PlatformIO: Initializing remote target...
2020-07-01T13:22:50 INFO gdb-server.c: Found 6 hw breakpoint registers
2020-07-01T13:22:50 INFO gdb-server.c: GDB connected.
<signal handler called>
Loading section .isr_vector, size 0x188 lma 0x8000000
Loading section .text, size 0x2fdc lma 0x8000188
Loading section .rodata, size 0x58c lma 0x8003164
Loading section .ARM, size 0x8 lma 0x80036f0
Loading section .init_array, size 0x14 lma 0x80036f8
Loading section .fini_array, size 0x8 lma 0x800370c
Loading section .data, size 0x98 lma 0x8003714
2020-07-01T13:22:51 INFO common.c: Attempting to write 16384 (0x4000) bytes to stm32 address: 134217728 (0x8000000)
EraseFlash - Sector:0x0 Size:0x4000 2020-07-01T13:22:51 INFO common.c: Flash page at addr: 0x08000000 erased
2020-07-01T13:22:51 INFO common.c: Finished erasing 1 pages of 16384 (0x4000) bytes
2020-07-01T13:22:51 INFO common.c: Starting Flash write for F2/F4/L4
2020-07-01T13:22:51 INFO flash_loader.c: Successfully loaded flash loader in sram
enabling 32-bit flash writes
size: 16384
.pioinit:15: Error in sourced command file:
Error finishing flash operation
2020-07-01T13:22:51 ERROR flash_loader.c: flash loader run error
2020-07-01T13:22:51 ERROR common.c: stlink_flash_loader_run(0x8000000) failed! == -1
2020-07-01T13:22:51 ERROR gdb-server.c: cannot recv: -2
2020-07-01T13:22:51 INFO gdb-server.c: Listening at *:4242...

When running st-util independently, I would consistently get the correct flash size.

2020-07-01T13:26:00 INFO common.c: F4xx: 192 KiB SRAM, 1024 KiB flash in at least 16 KiB pages.
2020-07-01T13:26:00 INFO gdb-server.c: Listening at *:4242...

Thanks for pointing out where to change the speed. I changed it to 100 KHz and reverted back to PIO debugging. Unfortunately this did not seem to make a difference… It still reports the incorrect flash size. Here is the output:

Processing genericSTM32F405RG (platform: ststm32; board: genericSTM32F405RG; framework: arduino)
--------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/ststm32/genericSTM32F405RG.html
PLATFORM: ST STM32 7.0.0 > STM32F405RG (128k RAM. 1024k Flash)
HARDWARE: STM32F405RG 168MHz, 128KB RAM, 1MB Flash
DEBUG: Current (stlink) External (blackmagic, jlink, stlink)
PACKAGES:
 - framework-arduinoststm32 4.10900.200602 (1.9.0)
 - framework-cmsis 2.50501.200527 (5.5.1)
 - toolchain-gccarmnoneeabi 1.90201.191206 (9.2.1)
LDF: Library Dependency Finder -> http://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 15 compatible libraries
Scanning dependencies...
No dependencies
Building in debug mode
Checking size .pio/build/genericSTM32F405RG/firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [          ]   0.7% (used 952 bytes from 131072 bytes)
Flash: [          ]   1.3% (used 13824 bytes from 1048576 bytes)
========================= [SUCCESS] Took 3.37 seconds =========================
Reading symbols from /home/levi/Documents/PlatformIO/Projects/vesc_test/.pio/build/genericSTM32F405RG/firmware.elf...
PlatformIO Unified Debugger -> http://bit.ly/pio-debug
PlatformIO: debug_tool = stlink
PlatformIO: Initializing remote target...
xPack OpenOCD, 64-bit Open On-Chip Debugger 0.10.0+dev (2019-07-17-11:25)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
hla_swd
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : tcl server disabled
Info : telnet server disabled
Info : clock speed 100 kHz
Info : STLINK V2J37S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.167750
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'gdb' connection from pipe
Info : device id = 0x10076413
Info : flash size = 8194 kbytes
openocd: /Host/home/ilg/Work/openocd-0.10.0-13/openocd.git/src/flash/nor/stm32f2x.c:1205: stm32x_probe: Assertion `(bank->size >> 10) == flash_size_in_kb' failed.
Aborted (core dumped)
.pioinit:13: Error in sourced command file:
Remote connection closed
10

…never before have I seen that the invocation of the same program in two different environment yields different results :sweat_smile:

Unfortunately even for stlink there are issues known regarding F4 flashing: STM32F1/F4/L0/L4: flash loader run error · Issue #607 · stlink-org/stlink · GitHub. A majority of them seems to indicate the re-plugging the USB cables helps for 1 flash run. Also a specific version is given which might not have that problem (1.4.0-53-ga201d3e), with this issue claiming it was fixed in the latest bleeding-edge version. You might give both versions a try. Apparently even openocd gets this wrong with the flash size.

I have no idea why it’s so inconsistent. The board is pretty standard on power and clock. The 3.3V is generated by a TC2117 low-dropout linear regulator from +5V or uses 3.3V directly. It has no low-speed external (LSE) oscillator for 32.768kHz but a 8MHz high-speed-external (HSE) crystal oscillator with a value of 8MHz and 15pF loading caps. The variant code tries to boot up from HSE XTAL first (code), if not there’s a fallback to HSI which needs no external components. 8MHz is also the expected value for the PLL parameters. Though it might not hurt to double-explicitly say build_flags = -D HSE_VALUE=8000000 in the platformio.ini to be double sure. If that is still failing in the RCC code for clock switches there must be something else that keeps this oscillator from swinging.

1 Like
11

Thanks for the info on stlink. I thought I’d boot into windows and give the official tool a try. It seems to detect the flash size correctly once Software System Reset is enabled in settings (it said 2KB with Hardware reset…). I compiled a blink sketch in PlatformIO and did a program and verify. It programmed alright, but still no blink. I then clicked on LiveUpdate and it appears the flash has made a mess of itself…

image
image1020×751 134 KB

This seems to happen after the reset, and values continue to change seemingly randomly even in Lockup and Hault…

12

Is NRST of the target boardf physically connected to the STLink? Have you tried without, or, pulling it to 3.3V? If flash contents change during execution or are erased, it might hint at a power problem or a faulty chip.

13

RST is connected. I have not tried without, but could try that.

Here’s the thing. I just was able to flash it with the original VESC firmware and it is perfectly functional. It uses openocd to flash it. This is with the same power etc. I’ve been testing with. Strange. I’ll try using openocd to flash the my bin.

14

Alright, so I’ve found that using the Adafruit Feather board configuration seems to work. I was originally trying the generic STM32F405RG configuration and I also tried the STM32F4Stamp configuration. With the generic one, the flash seemed to get messed up with invalid instructions, and execution would go into the weeds. With Stamp, execution would always end up in an infinite loop due to an unexpected interrupt. I haven’t had any issues with the Adafruit configuration so far. This is all reproducible on both Linux and Windows.

The issue seems to be in the build procedure (though apparently an issue in flash too causing the incorrect flash size, also seemingly fixed with the Adafruit config) because I tried a flash command that works on an .elf built with the Adafruit config on the other two, with an identical main.cpp (simple blink), and only the Adafruit one functioned. I flashed using openocd because that is what’s used in the VESC makefile.
openocd -f board/stm32f4discovery.cfg -c "reset_config trst_only combined" -c "program firmware.elf verify reset exit"
I dug into the board configurations to try and find what was different, but as far as I can tell they seem to use the same build and flash procedure according the the platform and framework. There are minor differences in the board jsons but those differences don’t seem to affect the execution of platform.py, builder/main.py or builder/frameworks/arduino.py. There must be some difference that I’m missing though otherwise they would all behave the same. I’m still curious what the difference/issue is, but I’ve already spent to much time debugging. Feel free to make speculations if you have any ideas.

@maxgerhardt Thanks so much for all your help on debugging this issue. I tried leaving NRST floating and pulled to 3.3V with no effect on the flash size error. I haven’t had any issues with that openocd command, and if it is reset related, maybe it has something to do with the "reset_config trst_only combined" part. My st-link just has one reset pin labeled RST.

15

Found the issue. Using the generic STM32F405RG variant, in variant.cpp on line 161 changing FLASH_LATENCY_1 to FLASH_LATENCY_5 Seems to have fixed all the issues I’ve been experiencing. Including any errors or warnings associated with flash size. If I understand correctly, this is the number of cycles delayed when fetching another block from flash.

Digging into flash latency, it looks like this could be further optimized/configured correctly according to AN3988.

1 Like