Sysprogs forums › Forums › VisualGDB › Issue with segger and flash erase/write
- This topic has 5 replies, 2 voices, and was last updated 4 years ago by support.
-
AuthorPosts
-
November 10, 2020 at 17:49 #29474jotuxParticipant
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.November 10, 2020 at 17:56 #29479supportKeymasterHi,
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.
November 10, 2020 at 18:38 #29480jotuxParticipantThere’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
Attachments:
You must be logged in to view attached files.November 10, 2020 at 19:01 #29484jotuxParticipantThe 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.November 10, 2020 at 19:56 #29486jotuxParticipantChanging the init script to this fixed my issue:
target remote :$$SYS:GDB_PORT$$
mon reset
mon ExcludeFlashCacheRange 0x0803F800,0x08003FFF
loadNote that the documentation for ExcludeFlashCacheRange (here: https://wiki.segger.com/J-Link_Command_Strings) is incorrect. It should be <start>,<end>, not <start>-<end>.
November 10, 2020 at 20:22 #29487supportKeymasterThanks for sharing this, it makes sense.
-
AuthorPosts
- You must be logged in to reply to this topic.