Flashing main application overwrites bootloader for STM32F413

[matsb]

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:

MEMORY
{
  PAGE0            (rx) : ORIGIN = 0x08000000, LENGTH = 16K                  /* FLASH page 0                                */
  BOOTLOADER_START (rx) : ORIGIN = 0x08000000, LENGTH = 16K - 20              /* Bootloader startup code + interrupt vectors  */
  BOOTLOADER_FW_ID (rx) : ORIGIN = 0x08003FEC, LENGTH = 20                    /* Bootloader firmware identification block    */
  PAGE1            (rx) : ORIGIN = 0x08004000, LENGTH = 16K                  /* FLASH page 1 - Misc parameters              */
  PAGE2            (rx) : ORIGIN = 0x08008000, LENGTH = 16K                  /* FLASH page 2 - Misc parameters              */
  MAINAPP_FLASH    (rx) : ORIGIN = 0x0800C000, LENGTH = 16K + 64K + (10 * 128K) /* Main Application FLASH memory 1360 kByte  */
  BOOTLOADER_FLASH (rx) : ORIGIN = 0x08160000, LENGTH = 128K                  /* Bootloader FLASH memory 16 + 128 kByte      */
  OPT_B            (rw) : ORIGIN = 0x1FFFC000, LENGTH = 16                    /* Options bytes single-bank                    */
  RAM            (rwx) : ORIGIN = 0x20000000, LENGTH = 320K                  /* Main RAM memory                              */
}

I.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

[embitz]

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.