The diagram below shows the most interesting parts of the pyOCD object graph, i.e. those parts that a user of the Python API will interact with. The connections in the diagram represent composition, not inheritance.
The root of the runtime object graph is a
Session object. This object holds references to the debug
probe and the board. It is also responsible for managing per-session options that control
various features and settings.
Attached to the board is a
CoreSightTarget instance, which represents an MCU. This owns the
CoreSight related objects for communicating with the DP and APs and a
CortexM object for each CPU
core on the device. Both
CortexM are subclasses of the abstract
class, which is referenced below, and share most of the same APIs.
CortexM has a memory map
MemoryRegion objects. The flash memory regions have a
Flash object to control flash
Targets and boards
Target and board support are two separate but related pieces of functionality.
Each supported target enables debugging and flash programming a given MCU. A single target can be
used for potentially multiple boards, or there may not be board with the target. Users can
override the target type on the command line or when creating the
Each supported target is defined as a
CoreSightTarget subclass. Builtin targets are held in a
Python file in the
pyocd/target/builtin directory. If the target has internal or connected flash,
then a flash algo dict and possibly a
Flash subclass will be paired with it in the same source
Flash subclass is only required if special flash programming semantics are needed,
otherwise the base
Flash class is automatically used. The flash algo dict and/or
are set on flash memory regions when they are created in the memory map. Some device families have
family subclasses under