Usually I compile my sources, link it and pass it to the debugger for downloading it to the target. And ‘downloading’ means for me: flashing to the target (RAM debugging is something for the non-hardcore programmers ;-)). But there are more options than only downloading and flashing. There is definitely more which helps me to do post-mortem (yes, I *love* Latin :cool:) debugging.

Downloading means to me that the debugger will program my application into the device, then loads the symbolics (debug information, source file information, …) and then I debug my application. Looking at the ‘Debug As’ options, there is as well Attach and Connect:

Post-mortem debugging is term I use to describe debugging my application which for example has stopped working. Usually I have an LED as a heartbeat, and after the application on the board was running for hours, days or weeks, the heartbeat LED stopped flashing. So my application crashed or is hanging somewhere. I cannot debug it in the normal way, as with this I would erase and re-program the application. What I need is a ‘hot-sync’ to the target: I need to connect my debugger to that application on the board and inspect what is going on. So I need to explore the different meanings of ‘download’, ‘connect’ and ‘attach’. And this is this post all about.

What is what?

Download is what traditionally is known as ‘debugging’: that’s the sequence of programming the device and then controlling it through the debugger. For this I need the application file (e.g. ELF/Dwarf file). And with it I have all the source level debug information.

Connect is establishing a debug connection to the target device. It does not program it, it just connects. So no application file is needed, and indeed ‘connect’ is very useful if I do *not* have the application file. I connect to the target, and then I can inspect it, without the need to know what is on it. *Very* useful for reverse-engineering :twisted:. But it means as well: as no source and symbolic debug information is available, this means debugging on assembly level. Still, very useful if I do not have the application at hand (or do not know it any more), and want to find out what the target is doing, or why it has crashed.

Attach is the same as ‘connect’, except that here I *do* have the project at hand on the target. That means with ‘attach’ I connect to a target and can debug it as usual. So ‘attach’ again is very useful to inspect a running (or maybe crashing) application on the device without erasing and re-programming the application on it. Attach is very useful too as it avoids the possibly lengthy process of flashing the application to the device. I did not make any change in my sources, I just wan to do another debug run? Then ‘attach’ saves a lot of time.

Connecting

To create a new ‘connect’ debug configuration, I use the menu Run > Debug Configurations. Here I select ‘CodeWarrior Connect’ and press the ‘new’ button:

💡 Hint: If I do not remember the difference between ‘attach’ and ‘connect’: the hint text at the top of the dialog explains that this is *without* an application, so no debug information will be needed or possible.

This creates a new configuration for attaching to the target: what it needs is how I connect to it (the connection):

❓ Wondering why there is a ‘Project’ for this? The reason is that Eclipse needs a project folder (or container) where it can store the configuration. So that project/container is not necessarily the application project I connect to.

Next I need to select a Connection: ideally I have already matching connection to the board I want to connect to:

❗ At the very least, I need a project as a container for the launch configuration settings. Plus I need a connection matching my board and my connection method (e.g. OpenSDA or P&E Multilink). An easy way is to use the new project wizard (File > New > Bareboard Project) to create a dummy project and the connection. It is very possible to create a new connection with the ‘New…’ button (see this post for all the important details).

And this maybe sounds like a cosmetic thing: naming the configuration to what it means is always helpful:

One very important ❗ thing to know is that ‘connect’ *is* using the Initialization settings (found in the Launch configuration > Connection Settings > Target Settings).

To get there, I press ‘Edit’ on the connection:

Then I press ‘Edit’ on the Target:

So if I do *not* want to reset and/or initialize the target, then I need to *disable* it here first:

Now I can press ‘Debug’ and it will connect to my target:

As expected: there is no source level debugging (thus “no source available”): but I have all the other views like Disassembly and Memory views which help me to understand the state of the target at the lowest level.

Attach

The other way is to ‘attach’. As outlined at the beginning, this means to connect to a board for which I do have the application file running on it. So it means the same as ‘connect’, but with debugging information.

Creating a new ‘attach’ configuration is similar to the ‘connect’ configuration: only this time I need to specify as well the application file (with the debug information) to use:

A very important detail to note here in the above dialog is this:

That indicates that in contrary to ‘connect’ described above, with ‘attach’ the reset and initialization settings *are* ignored. That means that if I do an attach, the target will be running, and I always need to stop it. And: debugging with an attach configuration allows me to debug it with source level debugging as I have provided the project and source level debug information with the application ELF/Dwarf file:

💡 Keep in mind that if enabled in the connection settings, the initialization scripts are executed as well as part of the attach operation. If not desired, then I can disable this in the target connection settings:

Summary

While in a typical development cycle the ‘download’ is used, the possibility of ‘attach’ and ‘connect’ are incredible helpful. ‘Connect’ allows me to connect to an ‘unknown’ target application, while with ‘attach’ I can inspect such as a device in the field without changing the application on it. Both are very useful to find and debug problems. One thing to keep in mind is that for ‘connect’ I need to *disable* reset and initialization if I want to stop the target as it is running.

Happy Attaching, Connecting and Downloading 🙂