Sysprogs forums › Forums › VisualGDB › Remote debugging in the time of covid-19
- This topic has 6 replies, 2 voices, and was last updated 4 years, 7 months ago by davidoz.
-
AuthorPosts
-
April 22, 2020 at 17:39 #27927davidozParticipant
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:
- 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.
- 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, 7 months ago by davidoz.
April 23, 2020 at 04:09 #27929supportKeymasterHi,
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).
April 24, 2020 at 05:54 #27934davidozParticipantHi 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
April 24, 2020 at 06:12 #27935davidozParticipantDon’t worry Support. I found where the DLL goes. Thanks.
April 24, 2020 at 10:33 #27936davidozParticipantHi 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, 7 months ago by davidoz.
April 24, 2020 at 18:28 #27940supportKeymasterHi,
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).
April 25, 2020 at 11:49 #27948davidozParticipantHi Support,
Yes, the new build works. Thank you for the quick resolution of this issue. The support from Sysprogs has been great.
Cheers
David
-
AuthorPosts
- You must be logged in to reply to this topic.