[Rumchiller]

I am using already 5.3 Preview 3 (build 1672). In addition, sometimes comments in functions and methods were also intending.

 

PS: Using VS2017 with all updates. Unfortunately I have this problem since I am using VisualGDB.

• This reply was modified 7 years, 4 months ago by Rumchiller.

[Rumchiller]

Again another pull 🙂

 

I have a problem with the visual studio auto formatting feature when formatting the whole document.

Let’s assume the following:

 

/**
* \brief Initializes Uart in 8-bit mode
* without parity bit.
* \param baudrate The Baudrate.
* \param s The Stopbit.
*/
Uart1(uint32_t baudrate,
StopBit s);

/**
* \brief Initializes Uart in 8-bit mode
* with parity bit.
* \param baudrate The Baudrate.
* \param s The Stopbit.
* \param p The Parity.
*/
Uart1(uint32_t baudrate,
StopBit s,
Parity p);

Now, when I do auto format I get this:

/**
* \brief Initializes Uart in 8-bit mode
* without parity bit.
* \param baudrate The Baudrate.
* \param s The Stopbit.
*/
Uart1(uint32_t baudrate,
StopBit s);
<p style=”padding-left: 30px;”>/**
* \brief Initializes Uart in 8-bit mode
* with parity bit.
* \param baudrate The Baudrate.
* \param s The Stopbit.
* \param p The Parity.
*/</p>

Uart1(uint32_t baudrate,
StopBit s,
Parity p);

 

After a new click on auto format:

/**
* \brief Initializes Uart in 8-bit mode
* without parity bit.
* \param baudrate The Baudrate.
* \param s The Stopbit.
*/
Uart1(uint32_t baudrate,
StopBit s);
<p style=”padding-left: 60px;”>
* \brief Initializes Uart in 8-bit mode
* with parity bit.
* \param baudrate The Baudrate.
* \param s The Stopbit.
* \param p The Parity.
*/</p>
Uart1(uint32_t baudrate,
StopBit s,
Parity p);

On each auto format the comment is intented further. This happens always when I’m working with overloaded methods.

Could you help me with that problem?

 

PS: Terrible WordPress… In short: The second block comment is intended to right on each auto format click. When I auto format the document a hundred times, the block moves 100 intends to the right.

• This reply was modified 7 years, 4 months ago by Rumchiller.
• This reply was modified 7 years, 4 months ago by Rumchiller.
• This reply was modified 7 years, 4 months ago by Rumchiller.
• This reply was modified 7 years, 4 months ago by Rumchiller.

[Rumchiller]

<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.

[Rumchiller]

I can confirm that, it’s working legendary :>

[Rumchiller]

It 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.

[Rumchiller]

So i got the issue today again:

Started debug session and stopped it immediately. After waiting for a minute i got a VisualStudio message:

While the message is showing, the debugger is running. When I click “OK”, the debugger is ending the session.

[Rumchiller]

Hi 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.

[Rumchiller]

I will reply if the error occurr next time and provide some infos about it. First for all thank you.

[Rumchiller]

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.

[Rumchiller]

We would recommend placing the Output window and the GDB Session window in different tab groups so that they can be displayed simultaneously.

Thanks for that hint. Logical.

 

Could you provide me a few informations about that “bad file descriptor”, what is it about? Maybe I could then discover which steps could be related to that problem. Even if I create a whole new project, e.g. HAL-Blinky, that problem occurrs.

[Rumchiller]

Normally this window appear, but in some cases it don’t. And then there is a long timeout. Worth mentioning: Normally VisualStudio goes into background, when it hangs, and is asking you, if you want to force it to close. But in this special case I can close it only via the task-manager. Or I must wait that minute.

[Rumchiller]

Sorry, I wanted to inform you about the ST-Link FW version, too:

V2.J27.S0

[Rumchiller]

Thanks for your response, yeah, the remote console is much better.

It would be yet nicer if i could decide where the console window would appear. I would appreciate it, if i could decide which informations will be where shown. It’s also very annoying (for me) that every time I start debugging, the “GDB-Session-Window” is staying on top, I have to click in the text-editor to hide it again. Similar to “Real-Time-Watch” and “Visual-Watch”, on each new debug session they are showing up again. Just take it as a possible feature request.

Indeed there are also lots of new gadgets and features in VisualGDB 5.2R8 which I greatly welcome. I love it.

 

Regarding ITM: I am using OpenOCD 0.9.0+ from your toolchain and working currently with the embedded ST-Link on the F4-Discovery. It works even with FreeRTOS without problems so far (except the non-blinking LED of the ST-Link).

 

Just one more thing:

When I stop debugging there opens a window (“Inline GDB Stub Output”) which says:

error during read: Bad file descriptor
dropped ‘telnet’ connection
error during read: Bad file descriptor
dropped ‘telnet’ connection

Could you help me with that?

 

PS: I am using “Visual Assist” with VisualGDB, it works really great.

[Rumchiller]

I’ve got it to work:

1. Let OpenOCD write the trace to a file ( e.g.   -c “tpiu config internal trace/output.txt uart off 168000000”), a pipe seems not to work under windows correctly.
2. Programmed a tiny C#-Console program, which is fetching the data in the file and print it right out.
3.  Added the program to a pre-debug-action in VisualGDB, so it is showing under “VisualGDB Launcher Output”.

Had to add some tweaks in my C#-Console, so the file will be deleted on startup and the console is closing itself when the “openocd.exe”-process ended.

 

But it’s annoying with the VisualGDB Launcher Output – window. I have to switch it each time from the dropdown-menu (“VisualGDB Program Output”, “VisualGDB Launcher Output”, …). It would be also very nice i could decide, if the console window is integrated in a specific window inside VisualStudio or VisualGDB or it will even open in a standalone-window.

 

EDIT: I encountered a problem. I am using the STM32F4Discovery-board and with the new added command-line-arg, the ST-Link LED is not flashing any more. However I can debug normally. Did you mentioned that as the problem?

• This reply was modified 7 years, 9 months ago by Rumchiller.
• This reply was modified 7 years, 9 months ago by Rumchiller.

[Rumchiller]

Since I’m playing around with the SWO-Trace channels I’m very interested in that possible solution. How do you accomplished that you could connect with telnet to the device, while VisualGDB is already connected? Indeed I am using OpenOCD.

 

Thanks in advance!

Reggie

• This reply was modified 7 years, 9 months ago by Rumchiller.

[Author]

Posts