Issue with segger and flash erase/write

Sysprogs forums Forums VisualGDB Issue with segger and flash erase/write

This topic contains 5 replies, has 2 voices, and was last updated by  support 1 week, 6 days ago.

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts
  • #29474

    jotux
    Participant

    I’m having an issue with the segger (v5.7) j-link interface somehow breaking flash access.

    I have a custom link script that reserves the last page of flash on my STM32L443 for user access (See attached project FlashWriteSample.zip, file ‘STM32L443CC_flash.lds’).

    I wrote a trivial sample program to unlock the flash and erase the last page. When I program and debug the program with an ST-Link 2.1, using the OpenOCD plugin, it works fine and erases the data from the last flash page. When I use my Segger J-Link Ultra+, the page does not erase. But if I use the Segger J-Flash utility to burn the same .bin file to the device, it does erase the page. This leads me to believe there is some issue with the Segger plugin used by VisualGDB. Maybe the Segger plugin is, for some reason, marking all memory as write-protected in debug?

    Images attached show what versions of plugins I have and the debug configuration of the ST-link and Segger when I see the issue.

     

     

    Attachments:
    You must be logged in to view attached files.
    #29479

    support
    Keymaster

    Hi,

    VisualGDB would normally just use the “load” command to program the FLASH memory and would not issue any locking commands. You can find out the exact commands used by VisualGDB by creating a gdb log file. You can try passing additional commands to the gdb stub (using the “monitor <command>” syntax) by expanding the “Advanced Settings” view under VisualGDB Project Properties -> Debug Settings. See the J-Link documentation for a list of monitor commands related to memory protection.

    If nothing helps, please consider checking with Segger support. They might be able to suggest a command for controlling the FLASH memory erasing.

    #29480

    jotux
    Participant

    There’s some sort of disconnect between segger and the debug output. If I run the code and log it as I step across the erase function, the memory does not change in the memory window of VisualGDB. I’ve attached the log showing the memory segment as 0x0803F800 does not change as I step.

    If I view the memory with J-Mem as I debug I can see that the memory does get erased but at the same time it does not display correct in the VisualGDB memory window.

    See gif of memory here: https://imgur.com/aPVNwjE

     

    • This reply was modified 1 week, 6 days ago by  jotux.
    • This reply was modified 1 week, 6 days ago by  jotux.
    Attachments:
    You must be logged in to view attached files.
    #29484

    jotux
    Participant

    The issue seems to be this “Allow caching of flash contents” setting in the J-Link GDB server. I’ll try to find a way to disable it from the commands in the debug menu.

    Attachments:
    You must be logged in to view attached files.
    #29486

    jotux
    Participant

    Changing the init script to this fixed my issue:

    target remote :$$SYS:GDB_PORT$$
    mon reset
    mon ExcludeFlashCacheRange 0x0803F800,0x08003FFF
    load

    Note that the documentation for ExcludeFlashCacheRange (here: https://wiki.segger.com/J-Link_Command_Strings) is incorrect. It should be <start>,<end>, not <start>-<end>.

    #29487

    support
    Keymaster

    Thanks for sharing this, it makes sense.

Viewing 6 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic.