Sysprogs forums › Forums › VisualGDB › Feature request: Cortex ITM/SWO support
- This topic has 22 replies, 3 voices, and was last updated 7 years, 8 months ago by support.
-
AuthorPosts
-
February 19, 2017 at 20:48 #10482RumchillerParticipant
Regarding the launcher output, please consider putting your program to Custom Debug Steps -> Remote Console -> Use the following command to start the console. It will put your program to a separate pane in Visual Studio and will provide better experience than just the launcher output.
Encountered a problem with that method: Somehow VisualGDB doesn’t allow my C#-Console to delete a specific file. This problem only occurs when it runs in the Remote-Console and not, how I did it before, in the Launcher-Output-Window.
February 20, 2017 at 03:09 #10487supportKeymasterHi,
The “bad file descriptor” message is shown by OpenOCD after VisualGDB closes the gdb session and is a normal response to the end of session, so aside from being an annoyance, this message is completely harmless and can be ignored.
Normally VisualGDB should not display this text as the session has already ended, but it looks like in some cases this check does not work properly. If you could let us know the circumstances that cause this message to appear, we should be able to fix the check and prevent the message from appearing after the session has ended.
February 23, 2017 at 19:14 #10528RumchillerParticipantHi again!
Really weird: Today i started debugging and that window do not appear any more! I will observe that problem, if it occurs again.
Could you help me with my problem about the custom action (own Remote Console)? Two Problems
1. When my Console-App runs in the Remote Console Window it can not delete a specific file. This works only in the Custom Action (“Before launching GDB”). Maybe the Remote Console is starting to late and another Program already locked that file. I would use the normal Custom Action, but then it runs in the “Launcher Output Window” (like described above).2. The Remote Console is autoscrolling. Though that’s a nice feature, it causes also problems, when I want to scroll up. In the Launcher Output Window, it is possible to click somewhere in the output and it stops autoscrolling. When click on the last output line, autoscrolling resumes.
February 23, 2017 at 20:04 #10529supportKeymasterHi,
This looks like some sort of a race condition that occurs very rarely. As the workaround is very simple (just close the window), we don’t prioritize fixing it unless someone reports a 100% repro scenario.
It is hard to say why your program cannot delete the specific file. We would recommend displaying a message box from your program before and after deleting the file and then using Process Explorer to check for open handles to that file and Process Monitor to check why delete fails.
You can disable the scrolling in the remote console window by right-clicking and selecting “Freeze contents”.
February 25, 2017 at 14:16 #10538RumchillerParticipantIt is hard to say why your program cannot delete the specific file.
It’s because OpenOCD is already writing in that file. That’s why I used the Custom Action (“Before lanuching GDB”) and not the Remote Console for my Console-App. But then I have the above described problems.
You can disable the scrolling in the remote console window by right-clicking and selecting “Freeze contents”.
Yes. But after de-freezing the new content is lost.
February 25, 2017 at 19:48 #10539supportKeymasterHi,
Thanks for the explanation. If you want to delete a file written by OpenOCD, please add a command for deleting it to pre-debug actions instead of doing it from the remote console program.
Regarding the output freezing, when you click “freeze”, VisualGDB will buffer the new text and will append it to the console once you unfreeze the output. If you believe some text is lost, we would appreciate the repro steps and would gladly fix this.
April 6, 2017 at 23:07 #10890RumchillerParticipant<pre id=”tw-target-text” class=”tw-data-text tw-ta tw-text-large” data-placeholder=”Übersetzung” data-fulltext=””>The “bad file descriptor” message is shown by OpenOCD after VisualGDB closes the gdb session and is a normal response to the end of session, so aside from being an annoyance, this message is completely harmless and can be ignored.
So today I got this message again (VS 2017). I did not change anything, but code and added new source and header files.
April 7, 2017 at 05:49 #10898supportKeymasterHi,
If it only occurs once every few months, it’s probably easier to just ignore it rather than to try locating the cause. If it starts occurring more often after some specific change, let us know and we will try reproducing it on our side.
-
AuthorPosts
- You must be logged in to reply to this topic.