Initializing a target

Some targets require more steps before establishing a debug connection. The exact nature of these steps will depend on the target that you are using. If you are working with an unfamiliar target, look through the user manual for the target, or consult the designers of the target, to determine the requirements for establishing a debug connection.

Here are some of the more common target initialization steps:

Powering up or taking a core or processor out of reset

As explained in Target state, there are various reason why a core or processor might be powered down or held in reset.

Here are some common steps that you can follow to put the core or processor into a better state for debug:

  • Perform reads and writes to memory or specific devices
  • Modify OS build or run attributes
  • Change firmware or target settings
  • Manipulate hardware elements, for example switches or SD cards
Unlocking scan chains or devices

Some SoC designers add locking devices or manipulate the debug hardware, so that users without certain information cannot access the debug logic on the target. These locking techniques prevent unprivileged users from debugging the SoC. These techniques are usually implemented late in the SoC development cycle. It is possible that earlier revisions of a target do not require unlocking, but later revisions do.

Here are some common steps that you can use to unlock the debug logic:

  • Feed certain patterns into the lock device on the scan chain
  • Perform reads and writes to memory and/or specific devices
  • Manipulate hardware elements, for example switches or jumpers
Multiplexed signals

Pin space on an SoC is usually limited. This means that less frequently used devices might have their signals multiplexed with other devices on the SoC. For example, the signals of the off-chip trace port, the Trace Port Interface Unit (TPIU), might be multiplexed with the General Purpose I/O (GPIO) signals.

Here are two common steps that you can follow to demultiplex signals:

  • Perform reads or writes to memory or registers
  • Manipulate hardware elements, for example switches or jumpers
Missing connectors

Because pin space on an SoC is generally limited, debug output lines on an SoC might be available, but the physical connector is not. If there is pinout space on the PCB, you can overcome this issue by soldering a connector to the board.

In the late stages of the development cycle, the debug socket for an SoC might not be physically available. This might be because the SoC designer does not want users to be able to debug the target, or, or because debug is available through a non-physical method, for example gdbserver. If no socket is available, consult the user manual for the target, or other resources, for example tutorials or community postings.

Previous Next