[feature] Writing hexfile with areas not only located on flash address (EEPROM, OTP)

[arabine]

• Programmer/board type: e.g , Stlink/v2-onboard
• Programmer firmware version: e.g STSW-LINK007 2.27.15
• Operating system: e.g Linux
• Stlink tools version and/or git commit hash: st-flash 1.4.0-25-ge9fe4e5
• Stlink commandline tool name: st-flash
• Target chip (and optional board): e.g STM32F469I-DISCO

Fails to flash with some HEX files.
Tested the HEX file provided by ST in the CubeMX archive.

Output:

st-flash --serial 303636424646333533353335344433 --format ihex write STM32469I-Disco_Demo_V1.2.0.hex 
st-flash 1.4.0-25-ge9fe4e5
2018-03-17T21:11:51 INFO common.c: Loading device parameters....
2018-03-17T21:11:51 INFO common.c: Device connected is: F46x and F47x device, id 0x10006434
2018-03-17T21:11:51 INFO common.c: SRAM size: 0x40000 bytes (256 KiB), Flash: 0x200000 bytes (2048 KiB) in pages of 16384 bytes
2018-03-17T21:12:01 INFO common.c: Ignoring 108 bytes of 0xff at end of file
2018-03-17T21:12:01 INFO common.c: Attempting to write -2005324888 (0x88792ba8) bytes to stm32 address: 134217728 (0x8000000)
2018-03-17T21:12:01 ERROR common.c: addr too high
stlink_fwrite_flash() == -1

Expected/description:

Should not fail, the last error code is scary: INFO common.c: Attempting to write -2005324888 (0x88792ba8) ...

[arabine]

Reply to myself: the binary may contain data that are located in an external memory. OpenOCD also fails to flash at weird addresses. The official STLink does have support of that for discovery boards.

[xor-gate]

If that is a EEPROM or OTP area it is not possible in the same hex file with openocd and stlink currently. Because they use different algorithms to program.

[arabine]

Yes for sure. Anyway maybe we could have a proper error message. I have tested with my own program, it is OK, either close this ticket or change it to a "nice to have" status.

[Nightwalker-87]

Related to #202 and #333.

[Nightwalker-87]

Closed due to inactivity and missing interest.