[ABANDONED] Memory area not defined in hex file gets erased/written (0xFF) when flashing

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • [ABANDONED] Memory area not defined in hex file gets erased/written (0xFF) when flashing

    Hi,

    in my current project at work we see a strange behavior when flashing the controller with the Segger J-Link, as it erases (or writes 0xFF) to memory area(s) which aren't defined to be programmed in the flashed Intel Hex-file.
    Target processor is STM32 F407IGT6.

    We have a minimal software (called backup-firmware in the memory layout graph) which basically manages entry to the controller's bootloader, CRC-check and some other small things.
    Also there's a block Main SW (main application) and an update marker section, which stores a 4-byte magic word for interaction between Backup-FW and Main-SW.

    The hex file for the Backup-FW flashes the whole memory area with 0xFF to ensure a complete blank initial state and writes the update marker to NORMAL_STARTUP = 0x00000000. This will be later done in factory before writing production data.
    The hex file for the Main-SW flashes only the Main-SW area (along with a pre-calculated CRC-32 by srec_cat).
    Flashing the Main-SW, regardless if using the ST Cube IDE, Segger JFlashLiteExe or Segger JLinkExe (Linux-Environment Ubuntu 20.04, JLink_Linux_V722b utilities)
    overwrites the update marker at 0x080F F800, which it shouldn't.

    Googling around, I found the following threads here in forum

    [SOLVED] J-link base without erase
    [SOLVED] JFlash overwrites incorrect pages

    which lead to playing around with the RMW threshold as described in
    wiki.segger.com/J-Link_Command…#SetFlashDLNoRMWThreshold.

    Setting in CubeIDE (*) the threshold to 0xFFFF which should write every blocks < 64 kB with Read-Modify-Write (as I understood) didn't change anything unfortunately although I'm pretty sure the option got accepted by the GDB server:
    (* Debug profile -> Startup -> Initialization Commands: monitor exec SetFlashDLNoRMWThreshold 0xFFFF)

    Source Code

    1. SEGGER J-Link GDB Server V6.94c Command Line Version
    3. JLinkARM.dll V6.94c (DLL compiled Feb 5 2021 17:38:32)
    5. Command line: -port 2331 -s -device STM32F407IG -endian little -speed 4000 -if swd -vd
    6. -----GDB Server start settings-----
    7. GDBInit file: none
    8. GDB Server Listening port: 2331
    9. SWO raw output listening port: 2332
    10. Terminal I/O port: 2333
    11. Accept remote connection: yes
    12. Generate logfile: off
    13. Verify download: on
    14. Init regs on start: off
    15. Silent mode: off
    16. Single run mode: on
    17. Target connection timeout: 0 ms
    18. ------J-Link related settings------
    19. J-Link Host interface: USB
    20. J-Link script: none
    21. J-Link settings file: none
    22. ------Target related settings------
    23. Target device: STM32F407IG
    24. Target interface: SWD
    25. Target interface speed: 4000kHz
    26. Target endian: little
    28. Connecting to J-Link...
    29. J-Link is connected.
    30. Firmware: J-Link V10 compiled Jun 17 2021 16:40:36
    31. Hardware: V10.00
    32. S/N: 50000899
    33. Feature(s): GDB
    34. Checking target voltage...
    35. Target voltage: 3.30 V
    36. Listening on TCP/IP port 2331
    37. Connecting to target...
    38. Connected to target
    39. Waiting for GDB connection...Connected to 127.0.0.1
    40. Reading all registers
    41. Read 4 bytes @ address 0x08000AFC (Data = 0xD0FA2B00)
    42. Read 2 bytes @ address 0x08000AFC (Data = 0x2B00)
    43. Connected to 127.0.0.1
    44. Reading all registers
    45. Read 4 bytes @ address 0x08000AFC (Data = 0xD0FA2B00)
    46. Read 2 bytes @ address 0x08000AFC (Data = 0x2B00)
    47. Received monitor command: WriteDP 0x2 0xF0
    48. O.K.
    49. Received monitor command: ReadAP 0x2
    50. O.K.:0xE00FF003
    51. Reading 32 bytes @ address 0xE00FFFD0
    52. Received monitor command: reset
    53. Resetting target
    54. Received monitor command: exec SetFlashDLNoRMWThreshold 0xFFFF
    55. Executed SetFlashDLNoRMWThreshold 0xFFFF
    56. Downloading 15840 bytes @ address 0x08010000 - Verified OK
    57. Downloading 16032 bytes @ address 0x08013DE0 - Verified OK
    Display All
    Interesting fact is, I've also a ST-Link v2 ISOL debugger here with which I did some experiments:
    It
    - behaves the same as the J-Link when flashing via CubeIDE
    - behaves the same using STM32 CubeProgrammer with default settings
    - behaves differently, meaning it preserves the update marker value at 0x080F F800 if the download option 'Skip flash erase before programming' is activate

    I also thought it may be associated somehow with the flash page size, which is AFAIK 2 kB for our controller, but the memory layout is aligned to 2 kB blocks.

    To be honest I'm completely lost at the moment, as I'm unable to tell why the J-Link (and ST-Link in CubeIDE) deletes/writes memory it shouldn't.

    Is there some kind of GDB-option or other setting I'm missing?
    There has to be some kind error in configuration and/or in the hex file(s) or everyone writing a booloader/application like software structure would have this problem, or am I wrong?

    Unfortunately, I'm not allowed by my company to upload the hex files here, but I'll attach screenshots of Segger J-Flash showing the affected memory area below

    Thanks a lot in advance for answers!

    Best regards
    Markus

    Backup-FW: Defining 0x080F F800 as 0x0000 0000


    MainSW: Defining only memory area of 0x0801 0000 to 0x080F F7FF