- This topic has 5 replies, 2 voices, and was last updated 9 years, 5 months ago by
.
-
Posts
-
Hi,
I’m using the STM32F1xx Embedded Microcontroller with the Segger j-link (Version Setup_JLink_V496b) and Visual GDB Version (VisualGDB-4.3r4).
I’m having problems viewing the Visual Studio Memory Window in Debug mode.
To explain:
1) I’ve defined an area of flash memory in my code for non volatile settings, that is at a fixed location in flash. Default values are loaded into it (as defined by the code) when initially programmed.
2) When settings are altered by my code, the new settings are written to the flash location (using standard flash read/write/erase methods). I can confirm that this code works OK.
3) I have the ability to read the contents of that settings memory via a serial communications channel. Using this communications channel, I can verify that the settings flash area changes from its default / initial values, when settings are altered.
4) When I try to view the settings flash memory area using the Memory window (Menu->DEBUG->Windows->Memory->Memory 1), I only see the initial contents of the flash – i.e. they do not appear to be the live settings / values that have just been written.
5) The Intellisense values (when I’m debugging) tie up with the values in the Memory Window – i.e. also not live.
6) The JLinkGDBServerCL window displays that it is Reading the correct number of bytes from the correct flash start address (when requested), so I’m not sure why this is not displaying the ‘live’ values.Is it the case that if the memory address requested to be displayed is flash in nature, then the data is assumed to be read-only and thus not expected to change, therefore assumed to be fixed at its initial value?
If the Memory window does not report ‘live’ values, then it’s dangerous to use.Any ideas?
Thanks in advance.
Hi,
Looks like the old values get cached at some point. The first step would be to see whether the caching happens on GDB level or on Segger level.
Please try issuing the following command in the GDB session window:
mon mem32 <address>, <bytes> (see this PDF for details: https://www.segger.com/cms/admin/uploads/productDocs/UM08001_JLink.pdf)
Does it show the new or old memory contents?
Hi,
Thanks for getting back. The command: “mon mem32” is not available in my GDB Session Window.
It is available from the J-Link Commander prompt (SEGGER software). If I look at the memory via J-Link Commander, the memory is correct. The PDF file that you sent me (section 5.11 “Command strings” details this).
In the GDB session window, the only command that appears to do what you suggested is the “MemU32” command (Full list of available commands returned via “mon help”). This returns the data at the address. When tried, this data is NOT correct (i.e. it’s the old value, not the new).
From your reply and these results, this indicates (to me) that the old values are getting cached at the GDB level.
Any ideas on how to stop this ‘cacheing’??Hi,
Looks like the command syntax has changed in the newer versions. Please try the following command:
mon memU8 0x<address>
or
mon memU32 0x<address>
Hi,
Thanks for getting back. Already tried using the “MemU32″ command. As stated in last post:
If I look at the memory via J-Link Commander (SEGGER software), the memory is correct.
In the GDB session window, the “MemU32″ command returns data is NOT correct (i.e. it’s the old value, not the new).
From your reply and these results, this indicates (to me) that the old values are getting cached at the GDB level.
Any ideas on how to stop this ‘cacheing’??Thanks,
Hi,
Sorry for the misunderstanding. The “MemU32” command is handled by the Segger GDB stub directly, so the caching actually happens inside the Segger stub.
From a quick look (“mon help” command) it seems that it does not have a specific command for resetting the cache. Please try one of the 2 options:
1. Contact Segger support. They should be able to suggest a workaround or release a hotfix.
2. Try using OpenOCD. It is less stable and usable than the original Segger software, but it may not have the cache problem.
If nothing helps, ensure that the problem is not caused by the CPU cache. Try reading one specific word from FLASH to a local variable in your firmware and examine the value of this variable using the debugger. If the value is also wrong, you need to reset the CPU cache.
- You must be logged in to reply to this topic.