Debugging CAPL

Debug the claim, then the code

“An alarm appeared while speed was below the threshold” does not identify the sender or the condition that triggered it. This exercise has two valid alarm sources. It shows how to distinguish a bad comparison from an incomplete explanation of a correct event.

Run one Simulation Setup node in an isolated CAN1 configuration, with classical standard ID 0x220 reserved for this exercise. No DBC or hardware is required by the model. The values below are deliberately named raw values, not rpm or degrees. This teaching source has not been compiled or run here; use the installed CANoe compiler and help to verify it first.

One reproducible case, two possible sources

variables
{
  long speedRaw;
  long temperatureRaw;
  long alarmRequests;
  message CAN1.0x220 alarm;
}

void requestAlarm(byte reason)
{
  alarm.RTR = 0;
  alarm.DLC = 1;
  alarm.byte(0) = reason;
  alarmRequests++;
  write("[Alarm] request=%d reason=%d speedRaw=%d temperatureRaw=%d",
        alarmRequests, reason, speedRaw, temperatureRaw);
  output(alarm);
}

on start
{
  speedRaw = 0;
  temperatureRaw = 0;
  alarmRequests = 0;
}

on key 's'
{
  speedRaw = 3200;
  write("[SpeedCheck] raw=%d hex=0x%X threshold=5000",
        speedRaw, speedRaw);
  if (speedRaw > 5000) requestAlarm(1);
}

on key 'h'
{
  speedRaw = 6000;
  write("[SpeedCheck] raw=%d threshold=5000", speedRaw);
  if (speedRaw > 5000) requestAlarm(1);
}

on key 't'
{
  temperatureRaw = 110;
  write("[TemperatureCheck] raw=%d threshold=100", temperatureRaw);
  if (temperatureRaw > 100) requestAlarm(2);
}

Start measurement, press s, then t. The expected sequence is a speed check of 3200 followed by a temperature alarm with reason 2. There is no contradiction: the speed condition was false, but the temperature condition was true. These are derived expectations, not captured execution logs.

The one-byte reason field is part of this teaching protocol. It gives the receiver observable evidence of the selected path. A log-only source label would help the sender's debugger but could not be inferred from an otherwise identical bus frame.

Follow the evidence through four observation points

1. Input: confirm the key event and its assigned value. If a real version uses CAN input, verify channel, direction, ID, frame kind and DLC before accessing payload bytes.
2. Decision: place a breakpoint on the comparison, before the conditional call. A breakpoint only inside the body guarded by a false condition will never trigger and cannot explain another handler's activity.
3. Request: inspect reason, alarmRequests, and the payload immediately before output. Search the entire configuration for every sender of 0x220; one source file is not the whole configuration.
4. Observation: inspect Trace and the receiver separately. A request counter proves calls made by this node, not successful delivery. Correlate channel, ID, payload and time with other nodes disabled.

Debugger menus and shortcuts vary by release. Use the installed UI for breakpoints, stepping and watches instead of assuming a fixed key combination. Pausing execution can distort real-time behavior; use breakpoints for state inspection and a separate unpaused trace for timing conclusions.

Three misleading readings to eliminate

Decimal and hexadecimal are different displays of one value

Decimal 3200 is hexadecimal 0xC80. Hexadecimal 0x7D0 is decimal 2000. A change in display radix does not change the stored value or turn a false comparison into a true one. Check the type, value and scaling before editing the threshold.

A local variable does not reset just because its handler returned

CAPL local variables have persistent storage across calls. If an accumulator should start fresh, assign zero on each invocation; if it should persist, initialize it deliberately and document when it resets. Moving every local variable into variables is not a fix for a lifetime misunderstanding. The basics exercise contrasts declaration initialization with explicit assignment.

A timer's type determines the delay unit

For timer t, setTimer(t, 100) requests 100 seconds. For msTimer t, it requests 100 milliseconds. Inspect the declaration first. Do not rely on invented t.active or t.time members: use APIs documented for the installed version and record entry timestamps or an explicit diagnostic counter. timeNow() uses 10-microsecond ticks, not nanoseconds.

Diagnose one layer at a time

Change one variable in the experiment at a time. Preserve a failing input sequence and the corresponding trace before modifying the source. After a fix, repeat both the positive case and a case that must remain negative; an unconditional alarm would “fix” reception while destroying the requirement.

Record enough to reproduce the result

Keep the source revision, CANoe version, configuration, channel mapping, enabled senders, input sequence, expected branch, actual log/Trace evidence and unresolved differences. Leave the actual result blank until executed. A screenshot of a green report without those inputs cannot establish what was tested.

The lifetime and time-unit rules follow the authorized Vector reference. The two-source experiment and diagnostic decision table are this site's analysis. Continue with the simulation model.