I am using Openocd to debug my code remotely for STM32 via Raspberry pi as detailed in this tutorial: https://learn.adafruit.com/programming-microcontrollers-using-openocd-on-raspberry-pi
Whenever I run openocd it starts gdb server on port 3333 which is default of course as shown in the picture above. My question is that, is there a way to provide a different port number for openocd to start the gdb-debugger on... For example, if I want to run openocd where i want gdb server to start on 3334 instead of 3333 how can i do that.
I intend to do that so that i can run multiple openocd instances for different targets simultaneously connected to a single raspberry pi. Any help will be greatly appreciated. Thanks in advance.
OpenOcd manual explains how to select a specific port number inside the configuration file as shown in image below:
Related
I've already set up a remote run configurations in CLion.
The remote server check is available, and the code has been synced to remote server.
However when I debug in clion, it always show error:
com.jetbrains.cidr.execution.debugger.backend.gdb.GDBDriver$GDBCommandException: To open a remote debug connection, you need to specify what
serial device is attached to the remote system
(e.g. /dev/ttyS0, /dev/ttya, COM1, etc.).
Debugger disconnected
How to specify the serial device?
No perfect, but working solution (for me)
Run->Edit Configurations->GDB: change from Bundled GDB to <path to gdb>
If you using Linux, it should be something like /usr/bin/gdb.
I am currently following the Coral Dev Board configuration guide using a MacOS machine running Catalina as my host machine. As per the instructions, for me to use the MDT command line tools on my specific host machine I must manually configure mdt. I used the following guide step-by-step but end up with the following error when I try to connect to the board.
Waiting for a device...
Connecting to jumbo-goose at 192.168.0.78
Key not present on jumbo-goose -- pushing
It looks like you're trying to connect to a device that isn't connected
to your workstation via USB and doesn't have the SSH key this MDT generated.
To connect with `mdt shell` you will need to first connect to your device
ONLY via USB.
Cowardly refusing to attempt to push a key to a public machine.
I would greatly appreciate if someone would be able to assist me in debugging this issue. I have reflashed my device a few times so I am unsure where the issue is emerging.
On the Coral Dev Mini I had similar issues with generating ssh keys, especially when I switched from a Windows to Linux machine. The easiest was (though not as secure) is to follow these steps and allows ssh with a password. First you will need to connect with a USB cable.
https://serverpilot.io/docs/how-to-enable-ssh-password-authentication/
To edit use sudo nano /etc/ssh/sshd_config
The key is to set: PasswordAuthentication yes
Check the sha25sum of the key file transferred to the dev board is the same as on MacOS, mine didn't match i.e the cut and paste wasn't quite right. With key file transferred manually using a SD card it worked first time on mdt devices/mdt shell commands.
I've been setting up remote debugging for an embedded Linux target. I've tested that I have the correct combination of gdbserver running on the target and gdb client running on my workstation. I can start the server and on the workstation side run:
(gdb) target remote 10.28.22.226:2345
and I can list source and step just fine.
In Qt Creator I have configured a device. In that window I specify the GDB server executable: gdbserver (see pic).
I also configure the cross debugger in the 'Build & Run' Debuggers tab as shown below:
In this case, I have manually started the gdbserver with my executable on the target with port 2345. To start debugging with Qt Creator, I choose the Debug->Start Debugging->Attach to running Debug server pulldown menu. It gives me the prompt shown below, where I enter the server port (2345). I give it the appropriate kit and local executable (copy of the executable on the remote target).
After I hit OK, it seems to run the gdb client locally with a few commands, then times out trying to communicate with the gdbserver. I have debug logging turned on with the server, so I know the server never sees anything from the client run from Qt Creator. Additionally, I did Window->Views->Debugger Log to help me get a better idea of what was going on. The log shows the correct IP address and port for my device, but I don't see anything that looks like a 'target remote IP:port' call.
I'm looking for a hint or reference here. I seem to be a bit stuck at the moment. Thanks!
EDIT: additional information - I've verified that my gdb client has support for python compiled in. I see that Qt Creator requires python support. I also have further support that nothing ever goes out on the wire from Qt Creator. I did a wireshark capture and don't see anything going to port 2345 on the target.
Alternately, if anyone would share their Qt Creator debugger-log output with me so I can compare, that would be helpful.
Avoid Qt Creator 4.5-beta1. It seems 4.5RC1 doesn't have this problem. I was able to do remote debugging using the method described above just fine.
Even QtCreator 4.5.0 seems to have the same bug.
The only workaround I've found is to start the GDB server manually on the remote target: with "top" I get the pid of the remote process to debug then I run the following command: gdbserver --attach remote ip:remote port pid.
After the server is listening, I finally choose: "Attach to Running Debug" server".
Maybe you can write a server start script on target which include the above statement...
I am trying to figure out why my Travis CI tests fail here. It looks like an infinite loop in one of the programs and I'm eager to run gdb there and take a look inside. I assume that the Travis instance is behind NAT, so just connecting to a GDB server would be complicated. Is there a way to make the gdb server connect to me? Do I have any alternatives?
Here's what I found:
https://github.com/fniephaus/travis-remote-shell
This is a project that uses Ngrok to open a TCP port and then creates a reverse shell there. I hadn't tried it though.
What is the difference between gdb mi and gdb server? Can both be used for local debugging?
I have facing problem in troubleshooting the debugging with gdb server on Red Hat. The debugging launcher stops at 72 %.
For local debugging you need neither MI or gdb server. You only need gdb.
MI is used by various GUIs/IDEs to communicate with gdb. This basically changes commands so they can be better parsed by machines (hence the name Machine Interface).
Gdbserver is used to debug remote systems. You only run gdbserver on remote (target) machine (this can for example be some embedded system running linux) and then you connect to gdbserver from GDB on your workstation (serial, ethernet or similar). This allows you to debug on your workstation and only requires target to run simpler gdbserver.