Remote debugging in the time of covid-19

[davidoz]

Hi All,

I need to debug my application, but due to closed borders the hardware is 3500Km away.  I changed the GDB command in VisualGDB to connect to the remote computer (target remote <hostnname>:xxxx).  To get it working I have to manually run OpenOCD on the remote computer.  Debugging works, except VisualGDB still runs an OpenOCD locally which is unnecessary.  If there is a cleaner way of doing it, can you please let me know.  (btw I couldn’t get the Custom GDB Stub method working).

I also have a couple of minor issues:

1. Downloading firmware doesn’t work. I have to do that manually on the remote computer.  It’s complicated because I use a Flash Driver to load the firmware into external nor flash (using the sysprog tutorial).  Does anyone know what could stop the download from working remotely?  It looks like something is timing out during the erase external flash.  I’ve tried increasing the “set remotetimeout” but it has not affect on the timeout.
2. Fast semihosting doesn’t work.  When the firmware calls InitializeInstrumentingProfiler() it hits a break point.  Is there an issue with semihosting when connected remotely?

Cheers

 

 

 

 

• This topic was modified 4 years ago by davidoz.

[support]

Hi,

The fast semihosting and using the custom FLASH drivers requires a secondary telnet connection to OpenOCD that runs in parallel with the regular GDB connection.

Normally, VisualGDB would automatically configure OpenOCD to open a telnet port, and would then connect to it. However, for remote setups this won’t work. As a workaround, please try this build: https://sysprogs.com/files/tmp/OpenOCDPackage2.dll

Then locate the PreferredTelnetPort element in the .vgdbsettings file and set it to a non-zero value (e.g. 4444). Add the following element next to it:

<TelnetHostName>[IP address of the machine actually running OpenOCD]</TelnetHostName>

Make sure that port is open in the firewall on the remote machine, so that VisualGDB can connect to it (you can recheck it with the actual telnet tool).

[davidoz]

Hi Support.  Thanks for your advice.  I’ve downloaded the file.  On my machine it has an extension of *.dll.  Is it really a DLL and if so where does it go?  I know we’ve had an issue with your server (or the internet) changing the extension of files in the past.  I’ve tried renaming the extension other things, but nothing worked.

Cheers

David

[davidoz]

Don’t worry Support.  I found where the DLL goes.  Thanks.

[davidoz]

Hi Support,

I think it’s close to working.  I copied the new DLL to the host computer and remote computer (just in case).  I also modified the settings file to this:

<PreferredTelnetPort>4444</PreferredTelnetPort>
<TelnetHostName>10.10.243.100</TelnetHostName>

So I launch OpenOCD on the remote computer manually like this:

com.sysprogs.arm.openocd\bin\openocd.exe -c "bindto 0.0.0.0" -c "gdb_port 65085" -c "telnet_port 4444" -f interface/stlink.cfg -f target/stm32f0x.cfg -c init -c "reset init" -c "echo VisualGDB_OpenOCD_Ready"

It outputs this:

VisualGDB_OpenOCD_Ready
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections

I then start the debugger on the host computer.  It downloads the firmware to the micro on the remote computer, and then starts running the firmware.  A dialog appears saying the debug method doesn’t work with semihosting.  I click ok and the firmware continues.  It does not attempt to make the telnet connection (confirmed by wireshark).

I can start a telnet connection manually on the host computer and it connects to the remote computer on port 4444.  However, I don’t see any of my semihosting messages.  I send this command through the telnet:

arm semihosting enable

It confirms semihosting is enabled, but still no messages.

I’ve traced the firmware.  I see _write() call your <span>WriteToFastSemihostingChannel()</span> function, but after that I lose it in the assembler.

VisualGDB still launches a local OpenOCD even though GDB is talking to the one running on remote computer.  I don’t know if that has anything to do with semihosting not working.

 

Cheers

David

 

• This reply was modified 4 years ago by davidoz.

[support]

Hi,

Sorry about that, the new build of the OpenOCD package requires an updated VisualGDB debug engine. Please try this build: VisualGDB-5.5.5.3577.msi.

If it still doesn’t work, please check if the Debug->Windows->Live Watch->Globals view works (and updates the variables properly).

[davidoz]

Hi Support,

Yes, the new build works.  Thank you for the quick resolution of this issue.  The support from Sysprogs has been great.

Cheers

David

 

[Author]

Posts