I have a STM32F030F4 controller on a custom board that has worked without issues so far. Running STM32CubeIDE in a Windows 10 virtual machine on Linux, I was able to flash/debug it through an ST-Link/V2 adapter.
Now the firmware has grown to 7176 (0x1c08) bytes long, and the built-in STM32CubeProgrammer can no longer flash it. Here's the console log:
STMicroelectronics ST-LINK GDB server. Version 5.3.2
Copyright (c) 2019, STMicroelectronics. All rights reserved.
Starting server with the following options:
Persistent Mode : Disabled
Logging Level : 1
Listen Port Number : 61234
Status Refresh Delay : 15s
Verbose Mode : Disabled
SWD Debug : Enabled
InitWhile : Enabled
Waiting for debugger connection...
Debugger connected
-------------------------------------------------------------------
STM32CubeProgrammer v2.2.0
-------------------------------------------------------------------
Log output file: C:\Users\ENTWIC~1\AppData\Local\Temp\STM32CubeProgrammer_a04824.log
ST-LINK SN : 48FF72068278535349170281
ST-LINK FW : V2J34S7
Voltage : 3.20V
SWD freq : 4000 KHz
Connect mode: Under Reset
Reset mode : Hardware reset
Device ID : 0x444
Device name : STM32F03x
Flash size : 16 KBytes
Device type : MCU
Device CPU : Cortex-M0
Memory Programming ...
Opening and parsing file: ST-LINK_GDB_server_a04824.srec
File : ST-LINK_GDB_server_a04824.srec
Size : 7176 Bytes
Address : 0x08000000
Erasing memory corresponding to segment 0:
Erasing internal memory sectors [0 7]
Download in Progress:
File download complete
Time elapsed during download operation: 00:00:03.384
Verifying ...
Error: Data mismatch found at address 0x08001C01 (byte = 0x10 instead of 0x00)
Error: Download verification failed
Encountered Error when opening C:\ST\STM32CubeIDE_1.1.0\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.win32_1.1.0.201910081157\tools\bin\STM32_Programmer_CLI.exe
Error in STM32CubeProgrammer
Debugger connection lost.
Shutting down...
If I add some stuff to make it 7180 bytes long, it works. If I remove some bits to get a length of 7168 bytes, it works. Flashing 7172 or 7176 bytes long firmware fails, everything else I've tried works.
So I've generated a .hex file in CubeIDE, and opened it in the ST-Link Utility. Comparing it with the target showed that they do indeed differ at 0x08001c01. The two words in the flash at 0x08001c00 are copies of the data at 0x08000000, stack pointer and reset vector, where there should be zeroes. Flashing the firmware with ST-Link Utility succeeds.
UPDATE: Increased the program size to 8196 (0x2004) bytes. Flashing fails the same way, but at address 0x08002001
Ugly workaround: changed ALIGN(4) to ALIGN(16) at the end of the .data segment
. = ALIGN(16);
_edata = .; /* define a global symbol at data end */
} >RAM AT> FLASH
so it won't be xxx04 or xxx08 again.
UPDATE2:
getting the same error again, so changed the alignment of the preceding section too
PROVIDE_HIDDEN (__fini_array_end = .);
. = ALIGN(16);
} >FLASH
no problems since then with these two changes in place.
