[adchester]

Thank for very much for the update and for doing this so quickly.

I am getting errors when I try to run because I cannot seem to establish a GDB connection between my PC and OpenOCD on the RPi (I had assumed that because I could establish a SSH connection then a GDB connection would work as well).

VisualGDB is licensed to Tatum Maskell at Silent Sentinel Limited
169.254.199.164:3333: No connection could be made because the target machine actively refused it.
“monitor” command not supported by this target.
You can’t do that when your target is `exec’

If I run GDB from the cmd window I get:

(gdb) target remote 169.254.199.164:3333
169.254.199.164:3333: No connection could be made because the target machine actively refused it.

Telnet to RPi OpenOCD is also not working although SSH to RPi is and I can also establish a VNC connection. I can establish a telnet connection from the PC to another RPi application, so this makes me think that the RPi OpenOCD application is not listening even though it says that it is.

However RPi OpenOCD seems to be listening correctly on ports 3333 (GDB) and 4444 (telnet) because I have done some testing on the RPi side using the loopback address 127.0.0.1 and telnet. It open the telnet connection on 4444 and it it opens and then immediately drops the GDB connection because the telnet protocol is being used (however I think this is a good indication that the GDB listener on port 3333 is up and running).

I have tried disabling the Windows firewall and have also checked the RPi firewall settings and nothing seems to be being blocked.

So this seems to be a telnet and GDB connection issue between the PC and the RPi OpenGDB app.

If you do have any ideas on this then I would be very grateful for some help however this does seem to be an issue on the RPi side so I am about to try on the RPi forum to see if they can help me

Thanks again for your prompt assistance and I will be back in touch if I hit any more problems on the VisualGDB side.

[adchester]

Update

Breakpoints do work sometimes if I set them up before running rather than create a breakpoint during running. However they still seem to fail about 70% of the time so debugging is difficult and slow and not being able to create breakpoints during run time is also quite limiting. So I am still in need of a solution to this issue.

[adchester]

Thanks for the advice for the link error. That did work to remove the error.

However the problem with the breakpoints remains and is a serious issue for me as I cannot effectively develop the firmware without this working.

The project is based on an ST example for stepper driver hardware on the nucleo boards. All the hardware pin configuration has been done via the STM32CubeMX utility to ensure that hardware conflicts do not occur so I do not think this could be the issue.

The breakpoints do not stop working after some point in the program flow because they always work at the global level. So I can set a breakpoint in the main.cpp while(1) loop and it will always be hit. So for example I have a switch in the main loop and I can set a breakpoint on the switch statement and step into each case statement. What I cant do is set a breakpoint in one of the case statements because although the embedded program seems to break, the UI program does not (it behaves as if the embedded program is still running).

 

 

 

[adchester]

The following error appears in the project build log when the “Fixed-size stack and heap” option is removed from the project. And, as mentioned, this error does not go away again once the “Fixed-size stack and heap” option is re-selected. I stress again though that my main concern is the breakpoints not working.

 

1>attempt to open VisualGDB/Debug/stm32f7xx_hal_wwdg.o succeeded
1>c:/sysgcc/arm-eabi/bin/../lib/gcc/arm-eabi/6.2.0/../../../../arm-eabi/bin/ld.exe: cannot find -l$$com.sysprogs.toolchainoptions.arm.compactcpp$$
1>collect2.exe : error : ld returned 1 exit status
1>VisualGDB/Debug/stm32f7xx_hal_wwdg.o

[Author]

Posts