@mreaves wrote:Can the debugger in Slick-edit be used to debug Arm code on a remote system (attached via) USB? If so what DLL and set up files does Slickedit need to chat to that hardware?
There are some other threads that describe setting up remote debugging using Arm, but let me give you some of the essentials.
1) If you are familiar with what you need to do remote debugging with command line GDB, you'll find setting things up to debug using the SlickEdit GDB intregration quite simple. Otherwise, I would suggest catching up on the principals of remote debugging with GDB.
2) First thing you are going to need is a cross-compiled GDB that supports your target Arm architecture. There are some preconfigured toolkits you can install out there, or you can get the GDB package and build it yourself.
3) Second thing is on the Arm side, you will need a gdbserver. SlickEdit can't help you with this, we consider anything that happens on the remote target side as something that is "over the wall". Your remote application will run on the remote target under the control of gdbserver, and you will be attaching GDB (through SlickEdit) to the configured IP address and port. If IP isn't an option, you can also do this over a serial port, but it is, of course, slower, and somewhat more difficult to configure.
4) Third thing you will need is your source code and the target application on your local host, so that GDB can get debugging symbol information and display source code locations. You could stuff the source code into a SlickEdit project to manage it. If you are really ambitious, you can also configure a SlickEdit g++ project to build your application. This has been discussed in other threads.
5) At this point, you have everything you might need to debug using command line GDB.
6) Now we can try connecting using SlickEdit. First we need to point SlickEdit at your cross compiled GDB. Go to Debug > Debugger Options... and switch to the "Configurations..." options page. Click on "Add..." and find the GDB executable, then hit OK. Then give it a name, such as "GDB 6.8 for Arm". Then hit OK.
7) Now, make sure gdbserver is up and running on the remote target.
8 ) Finally, go to Debug > Attach Debugger > Attach to Remote Process using GDB...
  a) The "File:" is the aforementioned target executable (step 4).
  b) Give the hostname and port, you may need to use an IP address for the Host,
    in the rare circumstances where you can trust your DNS setup.
  c) Switch to the "Remote Options" tab, and make sure that the GDB executable
    you configured in set 6 is the selected GDB configuration.
  d) Now hit OK, and we will attempt to connect.
9) Depending on how you started GDB server, your application may be initially paused, or waiting to begin execution. In this case, you may want to set breakpoints now, then hit "Continue" to get your application started.
10) A final note, on pausing execution. GDB doesn't do async well at all, so we have a proxy that sits between GDB and your gdbserver which allows us to force the target application to be stopped. If you disable the proxy, then you should expect not to be able to pause execution, or set breakpoints, etc.
This should be enough to get you off the ground. If you have problems getting started, remember that you will be better prepared to ask what is going wrong if you try the same scenario with command line GDB first and verify that the problem is not your basic setup.
