2

I use OpenOcd to flash the Elf image of a STM32 ARM Cmake project.

In the mem.ld script the origin address of the FLASH sector is assigned with an address offset to 0x08020200.

If the Elf file is written to the Flash using OpenOCD and the write_image command it seems like the ELF header is written to the FLASH at 0x08020000.

enter image description here

The application binary is correctly written to the flash at 0x08020200 (the first four bytes at 0x08020200 reflect the stack pointer value)

Since 0x08020200 is a address within the flash sector 5 (0x08020000 - 0x0803FFFF) i would expect the auto erase feature of the OpenOcd write_image command to erase the entire sector 5 (because only full sectors can be erased)

What could cause the ELF header to be written to flash at address 0x08020000 ?

I performed the following steps:

  • Manually erased the entire flash memory
  • Dumped the entire flash content with the OpenOcd dump_image command
  • Checked the dumped image represents a clear flash (all bytes 0xFF)
  • Flashed the test.elf file with the OpenOcd write_image command
  • Dumped the entire flash content with the OpenOcd dump_image command again
  • Checked the first four bytes at 0x08020200 reflect the stack pointer value
  • Checked content of flash at 0x08020000 -> ELF header was written to flash
Y. Wilkening
  • 63
  • 4
  • I edited your question to make it clear this is a CLion configuration/usage issue - I found the original wording, 'Flashing of ELF file causes ELF header to be written to Flash' a bit confusing. By the way, can you only see the ELF header in the flash, or the whole ELF file ? – Frant Aug 20 '20 at 12:48
  • 1
    openocd knows how to read and use elf files properly, how are you using the tool? – old_timer Aug 20 '20 at 16:59
  • @old_timer: my undestanding is that he is not using openocd directly, but through Jetbrain's [CLion](https://www.jetbrains.com/clion/) IDE. This is thefore likely a Clion configuration issue, not an openocd one, since, as you were pointing out, openocd does speak ELF. – Frant Aug 20 '20 at 19:15
  • I did some further testing today and my question was not correct at many points. Therefore i edited the original question. I also removed the CLion topic because i was able to reproduce the problem by just using OpenOcd directly. – Y. Wilkening Aug 21 '20 at 09:31
  • How exactly are you using `write_image` command? Do you use `type` argument? – domen Aug 21 '20 at 10:56
  • I have used write_image without the type argument. But i also tried the following command with same result: `-c "program test.elf verify reset exit"` – Y. Wilkening Aug 21 '20 at 11:21
  • That is very odd. I guess you could try converting elf to another format and flashing that. It's a workaround, but maybe it gives some insight into what's happening. – domen Aug 21 '20 at 11:46
  • What are the `dump_image` commands being used? Is it possible that it's dumping to an .elf file rather than a binary? – Tom Sep 10 '20 at 16:44
  • It is probably linker script problem. – 0___________ Dec 12 '20 at 11:32

2 Answers2

1

This is a problem with PT_LOAD section alignment in the elf file. OpenOCD has no way of knowing where to write the image as the elf header is bundled into the section with the actual firmware payload offset from a 64KiB boundary.

The fix I found for this is to use --nmagic on ld (linker). It will force the alignment to 4 bytes and eliminate the elf header from being inadvertently written to the target. Use 'readelf -l the.elf' to see the differences.

David Thornley
  • 1,278
  • 1
  • 12
  • 15
-1

I have the same problem when ELF header is programmed at the start of flash, but I have this problem with "stm32 programmer CLI" (not openOCD) and I fixed it by means HEX. If I use hex file instead ELF beginning of flash isn't corrupted.

Сергей Плетнев
  • 1
  • 1
  • it does not answer the question. OP is not asking `how to flash the image`? – 0___________ Dec 12 '20 at 11:32
  • I mean that this bug doesn't relate with openOCD. Because for download image you need to use some driver and when I use stm32 programmer CLI I see the same problem. And for checking I use stm32 programmer to download firmware (without openOCD) and I reproduce this bug for version 2.5 and 2.6. – Сергей Плетнев Dec 15 '20 at 09:38