- This topic has 23 replies, 2 voices, and was last updated 7 years, 7 months ago by
.
-
Posts
-
Information from Segger:
Visual GDB uses two instances of the J-Link DLL to connect to the target:
One for debugging (Go / halt / readmem for watch window/ etc….) and a 2nd one for the live watch.The 2nd one does not know that the first one started the core again(e.g. after a breakpoint or after reset and halt), therefore it assumes that the content of the RAM did not change.
Solution:
Sysprog needs to alter Visual GDB in a way that it uses only one instance of the DLL.
If Sysprog wants to do this and is facing issues, we would be happy to get in touch with them.Yes, we got all the necessary information from Segger and are expecting to release an update next week.
OK, we’ve fixed this. Please update your Segger debug package to version 3.3. We have added a new more reliable live memory engine based on the feedback from Segger.
Note that it’s somewhat slower than the old one, so we have also added an option that allows switching between the old and the new one. Let us know if this solves the problem.
Thank you to fix everything!
1. in the debug window displays the correct value readable variables:
Read 4 bytes @ address 0x20000590 (Data = 0x0000047B)
Read 4 bytes @ address 0x20000594 (Data = 0x00000006)
Read 4 bytes @ address 0x20000598 (Data = 0x00000248)
2. In the window are displayed correctly LiveVariables counters
3. The speed of the debugger has become a “normal” (50 s/sec)
Thanks, it works! ))I hope someday to LiveVariablese appears is the same management “registers” CPU/periphery.
Thanks again.
- You must be logged in to reply to this topic.