Load ELF erases flash sector to 0x00 instead of 0xFF

[RamiRosenbaum]

• Programmer/board type: Stlink /v1, /v2, /v2-clone, /v2-1)
• Programmer firmware version: ST-LINK SN : 066CFF495351885087234214, V2.J37.M26
• Operating system and version: Linux
• Stlink tools version: tag v1.6.0, built locally
• Stlink commandline tool name: st-util
• Target chip (and board if applicable): STM32L476VGT6

rami@rami-VirtualBox:~/rami/aurora/stm32/stlink ((v1.6.0))$ src/gdbserver/st-util 
st-util 1.6.0
2020-08-05T17:31:21 INFO common.c: Loading device parameters....
2020-08-05T17:31:21 INFO common.c: Device connected is: L4 device, id 0x10076415
2020-08-05T17:31:21 INFO common.c: SRAM size: 0x18000 bytes (96 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 2048 bytes
2020-08-05T17:31:21 INFO gdb-server.c: Chip ID is 00000415, Core ID is  2ba01477.
2020-08-05T17:31:21 INFO gdb-server.c: Listening at *:4242...

Expected/description:
I'm debugging a simple application via arm-none-eabi-gdb, connecting to st-util.
I'm loading the ELF with the load command.
The flash-sector, beyond the ELF is filled with 0x00 instead of 0xFF.
Same behavior on Windows.

Intel-HEX:

:020000040800F2
:10000000101000200900000880B586B000AF134B27
...
:10016000710000080C00002000000020A100000821
:040170000400002067
:040174000A0000007D
:0400000508000000EF
:00000001FF

GDB memory output:

(gdb) x/40bx 0x08000160
0x8000160 <main+144>:	0x71	0x00	0x00	0x08	0x0c	0x00	0x00	0x20
0x8000168 <main+152>:	0x00	0x00	0x00	0x20	0xa1	0x00	0x00	0x08
0x8000170 <main+160>:	0x04	0x00	0x00	0x20	0x0a	0x00	0x00	0x00
0x8000178:	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00
0x8000180:	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00

(gdb) x/32bx 0x080007f0
0x80007f0:	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00
0x80007f8:	0x00	0x00	0x00	0x00	0x00	0x00	0x00	0x00
0x8000800:	0xff	0xff	0xff	0xff	0xff	0xff	0xff	0xff
0x8000808:	0xff	0xff	0xff	0xff	0xff	0xff	0xff	0xff

As you can see, the 2KB sector is filled with 0x00.

[Ant-ON]

The error could be in the gdb server. It fills flash blocks by 0x00 pattern when add.

stlink/src/st-util/gdb-server.c

Line 804 in 0a6fe3a

new->data = calloc(length, 1);

It may be fix by

new->data = malloc(length);
memset(new->data, stlink_get_erased_pattern(sl), length);

[RamiRosenbaum]

I don't like to compare, but the STM32 ST-LINK Utility command-line interface (ST-LINK_CLI.exe) has a cool feature: ske (Skip Erase Flash), which doesn't modify the sectors it flashes to (except for flashing the ELF data, of course).
Is there an equivalent feature in st-util?

[chenguokai]

I don't like to compare, but the STM32 ST-LINK Utility command-line interface (ST-LINK_CLI.exe) has a cool feature: ske (Skip Erase Flash), which doesn't modify the sectors it flashes to (except for flashing the ELF data, of course).
Is there an equivalent feature in st-util?

If I got your ideas right, what you expect is that stlink skips erasing (some or all) sectors and flashes data (did you mean .data section in ELF or are you referring to generic data (segments)?) extracted from some file (ELF files in this case) directly. It seems to be trivial to implement.

BTW, is your original issue solved with the information from Ant-ON? If not you may give some further feedback. This seems to be better situated in a new feature related issue.

[RamiRosenbaum]

I'm sorry, but I'm mixing a feature request with a bug.
I'm new here, so please advice...

I meant all data to be written to the flash: .text, .rodata, initialization data, etc.
Easiest to describe is looking at the Intel-HEX (s19, etc.) representation of the ELF: it holds only the binary data to be written to the flash.
After flashing, the flash is updated only in the addresses of the iHEX fiile.
If we want to flash data to the following address (taking into consideration the minimal write-alignment, on STM32 flashes it's ~8 bytes) - no problem.
Why do we need the feature? there are good reasons, beyond the scope of this ticket.
Thanks.

[Nightwalker-87]

@chenguokai @Ant-ON Would one of you fancy to contribute here, having looked into this already?

[Ant-ON]

@Nightwalker-87 I fixed main problem in https://github.com/Ant-ON/stlink/tree/gdb_features