- This topic has 3 replies, 2 voices, and was last updated 7 years ago by
.
-
Posts
-
I updated VisualGDB to newest version – which is awesome, great work!
But with the debugging i had issues and now have them again.
I work with an STM32 µC. I tried J-Link, it was super slow, i tried OpenOCD stuff, wich wasn’t good either, i tried again J-Link, but with using the JLinkARM.DLL it was super fast and very good to debug.
With the new Version the interface is different and i cant directly use the JLinkARM.DLL again.
Debugging is super slow again…
Please help me get my debugging to work fast again 🙂
regards
Haqim.
Hi,
We actually removed the direct mode as it was causing race conditions inside the J-Link DLL and sometimes showing incorrect data. It should normally not affect the normal debugging speed, only the speed of the real-time watch. Can you confirm that all debugging is now slow? Would you be able to share the gdb log with the timing labels so that we could see if we can work around this?
OK, race conditions i don’t want, also …
I have around 5 seconds easily just for one step in code.
But maybe some settings with my framing isn’t working right, but i don’t see a solution at the moment.
I add some logs and a picture.
Hi,
Sorry, the logs you attached unfortunately don’t show any timing. You can enable generation of timestamped logs via VisualGDB Project Properties -> Advanced GDB Settings -> Save all low-level interaction with GDB.
Please also try using this build: http://sysprogs.com/files/tmp/VisualGDB-5.3.14.1892.msi
It resolves another issue related to Segger GDB stub and might solve the performance issues you are encountering as well.
- You must be logged in to reply to this topic.