Sysprogs forums › Forums › VisualGDB › STM32 frequency floats when debugging
- This topic has 25 replies, 2 voices, and was last updated 4 years, 2 months ago by support.
-
AuthorPosts
-
October 1, 2020 at 14:13 #29159VladTParticipant
Any news on my question? wait? Or is your product only LEDs to blink on STM32?
October 1, 2020 at 14:15 #29160supportKeymasterThanks for letting us know. Good to know it works now.
October 9, 2020 at 15:54 #29228VladTParticipantAny news on my question?
October 9, 2020 at 16:00 #29229supportKeymasterSorry, not sure what the question was. In the last post in the thread you mentioned that both frequencies work now.
If you have any other questions, please feel free to repeat them here and we will do our best to answer them.
October 15, 2020 at 03:53 #29257VladTParticipantDoes not work! The question remained unresolved… In that post, questions, not statements …
October 15, 2020 at 07:46 #29259supportKeymasterBased on what you have described, it looks like a specific code snippet is not working as expected. It looks like an issue with a specific piece of code, rather than a VisualGDB bug. Also, unfortunately, you have not provided sufficient context for us to understand what is going on.
If the same project behaves differently when built with the Keil IDE vs. VisualGDB, please consider following this tutorial to track down the changes.
If it doesn’t help and you believe VisualGDB is not working as expected, please provide us the steps we could follow on our side to reproduce the problem per our problem reporting guidelines and we will try to investigate it further.
October 16, 2020 at 10:30 #29274VladTParticipantif I give you a draft of my project that behaves “wrong” – is that enough?
October 16, 2020 at 10:39 #29275supportKeymasterPlease note that VisualGDB is a productivity extension to Visual Studio. It makes building and debugging projects easier, however it does not replace an actual software engineer. It cannot automatically write code based on a verbal description, or fix the code that does not work as expected.
Fixing code that does not work as expected requires an engineer to review the code, its context, specific MCU datasheet and the related board design, and likely to debug it on the hardware. This would require non-trivial time and would cost much more than we charge per license, hence we are not able to provide it as a part of our product support. If you would like an engineer to review your project and help you resolve issues with it, please consider hiring a 3rd-party consultant.
October 16, 2020 at 11:24 #29280VladTParticipantYou do not understand … I will prepare a draft of my project with instructions on what to take from it and what to do so that you can repeat the behavior …
October 16, 2020 at 11:28 #29281VladTParticipantQuestion: do you have a fluent Russian programmer? It’s hard for me to explain the subtleties in English …
October 16, 2020 at 11:54 #29282supportKeymasterPlease note that we are not able to review specific projects or code snippets for errors. Our support is limited to issues when VisualGDB itself is not working as expected. It does not cover the issues where the code itself is not working, or the target device is not behaving as expected. Having different clock dividers or different optimization levels will affect function timing and can trigger bugs in the code. This is to be expected and VisualGDB will not be able to fix those bugs automatically.
Please note the we only provide support in English.
We also have to prioritize the reported issues by the ease of reproducing/fixing it and the amount of affected users. Given the amount of resources already spent on the thread we will not be able to investigate it any further, or provide any further replies unless the issue starts affecting other users. Sorry.
-
AuthorPosts
- You must be logged in to reply to this topic.