![]() |
|
Flashing main application overwrites bootloader for STM32F413 - Printable Version +- EmBitz (https://www.embitz.org/forum) +-- Forum: IDE (https://www.embitz.org/forum/forumdisplay.php?fid=1) +--- Forum: Using EmBitz (https://www.embitz.org/forum/forumdisplay.php?fid=2) +--- Thread: Flashing main application overwrites bootloader for STM32F413 (/showthread.php?tid=237) |
Flashing main application overwrites bootloader for STM32F413 - matsb - 23-06-2026 Hello friends! We recently ported from STM32G473 (natively supported by EmBitz/EBlink) to STM32F413 (not natively supported). So I added CPU ID 0x463 and the new 1.5 MByte memory map to EBlink scripts. Attached .zip files for EBlink version 6.21. The linker scripts memory map looks like this: Code: MEMORYI.e. Bootloader lives on pages 0 and 15. Misc. user data is on pages 1...2. Main application lives on pages 3...14. When compiling both Bootloader and Main application, the produced .hex files are correct. When flashing the .hex files with STM32CubeProgrammer, it will write to the expected pages and leave the other untouched. This is working correctly. When writing Bootloader with EmBitz / Flash / Flash target, everything goes fine. But when writing Main application, also page 0, 1, and 2 are overwritten. When looking more closely at those 3 overwritten pages, they seems to contain the raw content of the main application .elf file. For example the ".ELF" signature is stored at address 0x08000000. Attached picture of the beginning of 0x08000000. This happens for both EmBitz 2.63 and 2.65 that I have been using. Any help appreciated! Here is the EBlink output when writing Bootloader: EBlink version 6.21-[299] by Gerard Zagema Interface USB# : 54FF6A066684565547522187 Interface type : STlink/V2 Target voltage : 3.24V Interface speed: 4000KHz Target detected: Cortex-M4 (r0p1) with FPv4_SP HW breakpoints : 6 HW watchpoints : 4 Fault unwind : Active (level 2) STmicro family : STM32F413 Detected FLASH : 1536KB Configured RAM : 320KB Reset: system Checking current flash content Reset: system Flashing sector 0, address: 0x08000000, length: 0x4000 Flashing sector 15, address: 0x08160000, length: 0x1710C Flash verify Flasher starts target Reset: system Here is the EBlink output when writing main application: EBlink version 6.21-[299] by Gerard Zagema Interface USB# : 54FF6A066684565547522187 Interface type : STlink/V2 Target voltage : 3.24V Interface speed: 4000KHz Target detected: Cortex-M4 (r0p1) with FPv4_SP HW breakpoints : 6 HW watchpoints : 4 Fault unwind : Active (level 2) STmicro family : STM32F413 Detected FLASH : 1536KB Configured RAM : 320KB Reset: system Checking current flash content Reset: system Flashing sector 0, address: 0x08000000, length: 0x4000 Flashing sector 1, address: 0x08004000, length: 0x4000 Flashing sector 2, address: 0x08008000, length: 0x4000 Flashing sector 3, address: 0x0800C000, length: 0x4000 Flashing sector 4, address: 0x08010000, length: 0x10000 Flashing sector 5, address: 0x08020000, length: 0x20000 Flashing sector 6, address: 0x08040000, length: 0x20000 Flashing sector 7, address: 0x08060000, length: 0x20000 Flashing sector 8, address: 0x08080000, length: 0x20000 Flashing sector 9, address: 0x080A0000, length: 0x3090 Flash verify RE: Flashing main application overwrites bootloader for STM32F413 - embitz - 23-06-2026 Well, somehow those lower three sectors contain data in your app .hex file. My guess would be that the linker file is not entirely correct for the standalone application version. I don't think EBlink is the problem here. It's nice that you were able to add support for that device yourself. If that's okay with you, I'll copy it into the EBlink Git repository. If you could create a small test project that reproduces the issue, I'd be happy to take a look at it. Just remove any sensitive parts, and you can send it to me via PM if you prefer. |