Quantcast

Documentation Center

  • Trial Software
  • Product Updates

Use Breakpoints During Debugging

Run the Simulation Until the Next Breakpoint

By default, the debugger has a special built-in breakpoint at the end of the simulation. You can define your own breakpoints, as described in Define a Breakpoint. To proceed in the simulation until the debugger reaches the next breakpoint, at the sedebug>> prompt, enter this command:

cont

You cannot set breakpoints for a Simulink® controlled block. Instead, set the breakpoint in the SimEvents® block that initiates the signal execution.

Point at Which the Debugger Suspends the Simulation

When you enter a cont command, the debugger proceeds in the simulation until it reaches the first point in the simulation that meets one of these criteria:

  • At or after specified time — The simulation time is equal to or greater than the specified time of a timed breakpoint, and the point in the simulation corresponds to an operation that the simulation log is able to show.

    If no event executions or relevant updates in signals at reactive ports occur at the specified time of a timed breakpoint, the debugger reaches that breakpoint when the simulation time is strictly later. For example, if time-based blocks in a hybrid simulation have a discrete sample time of 1 and running the simulation without breakpoints causes the simulation log to report operations only at T = 0, 2, 4,..., then a timed breakpoint at T = 3 is equivalent to a timed breakpoint at T = 4.

  • At execution or cancelation — The simulation is about to execute or cancel the specified event of an event breakpoint.

  • At operation of a block — The block associated with a block breakpoint is about to perform an operation that the simulation log is able to show. For a list of block operations at which the debugger can suspend the simulation, see Block Operations for Block Breakpoints.

  • At operation on an entity — The block associated with a entity breakpoint is about to perform an operation that the simulation log is able to show. For a list of entity operations at which the debugger can suspend the simulation, see Block Operations for Block Breakpoints.

  • At end — The simulation is about to end. This condition corresponds to the built-in breakpoint at the end of the simulation.

The debugger reaches a given timed or event breakpoint zero or one time during the simulation. The debugger can reach a given block or entity breakpoint an arbitrary number of times during the simulation.

Unless all breakpoints are timed breakpoints, you might not be able to predict which breakpoint the debugger reaches next. Even though events have scheduled times, the debugger might reach an event breakpoint upon the cancelation of an event. You might not be able to predict the cancelation.

Ignore or Remove Breakpoints

The table describes options for preventing the debugger from observing a particular breakpoint.

Treatment of BreakpointsAt sedebug>> Prompt, Enter...Result
Ignore a particular breakpoint while keeping it in the list of breakpoints and being able to reinstate it easilydisable b1, where b1 is the breakpoint identifierThe list of breakpoints indicates the breakpoint as disabled and the debugger does not observe the breakpoint. You can reverse this operation using enable b1.
Ignore a particular breakpoint without keeping it in the list of breakpoints and without being able to reinstate it easilybdelete b1, where b1 is the breakpoint identifierThe breakpoint no longer appears in the list of breakpoints, so the debugger does not observe it.
Ignore all timed and event breakpoints and run the simulation until the endruntoendThe simulation runs to completion and the debugger session ends.

To view breakpoint identifiers, at the sedebug>> prompt, enter breakpoints.

    Tip   You can apply disable, enable, or bdelete to multiple breakpoints in one command by using all or a cell array as an input argument. For exact syntax, see the reference page for each function.

Enable a Disabled Breakpoint

To reinstate a breakpoint that you previously disabled:

  1. View breakpoint identifiers. At the sedebug>> prompt, enter this command:

    breakpoints
  2. Enter a command like the following, replacing b1 with the identifier of the breakpoint that you want to reinstate:

    enable b1

You might want to disable and enable a breakpoint to focus on behavior of a block during a particular time interval. A block breakpoint helps you focus on that block. Disabling the block breakpoint, when the simulation time is outside the time interval of interest, helps you focus on only those periods that are relevant to you.

Was this topic helpful?