Exclusive to Traxcope | Tutorial 10
Event-based firmware capture
Capture intermittent firmware failures with Trigger Studio.
Trigger Studio is a Traxcope-exclusive workflow for detecting a rare overvoltage event, preserving the activity that led to it and reviewing every synchronized view at the exact capture window.
Tutorial at a glance
The complete capture setup in four values.
The simulated 24 V bus-voltage variable.
Fire only when Vbus crosses the limit upward.
Keep the lead-up and the response in one capture.
Prevent repeated captures from the same short event burst.
The debugging problem
When the failure is known but its timing is not.
Intermittent firmware failures rarely wait for an engineer to open the right view. A signal may cross its limit once in hundreds of cycles, a task may exceed its timing budget only under a specific load, or a fault may appear only when two otherwise normal conditions overlap.
Continuous recording preserves data, but it can leave the engineer searching through a long timeline. Watching a live graph manually has the opposite limitation: the relevant moment can pass before it is noticed. A breakpoint is even less suitable when the behavior depends on real-time execution because stopping the target changes the system being investigated.
Available exclusively in Traxcope, Trigger Studio addresses this gap with event-based capture. You define the condition that represents the failure, arm the trigger and let the application continue to run. When the condition is met, Traxcope preserves the chosen interval before and after the event. The result is a focused capture with the surrounding runtime context still attached.
The central idea: do not wait for the rare fault and then search backward. Define the fault first, then let the capture come to you.
Tutorial scenario
A 24 V power system with an intermittent clamp delay.
Tutorial 10 starts from the T01 initialization project and uses the same FreeRTOS configuration introduced in the earlier FreeRTOS tutorial. The demonstration application models a 24 V power system with a load-dump event and an overvoltage clamp.
During normal operation, the simulated bus voltage stays near 25.5 V. Once every second, the application disconnects the load. Load current falls to zero and the bus voltage begins to rise. The overvoltage clamp should react before Vbus reaches the critical 33 V limit, then return the bus below 26 V.
Overclamp
The highest-priority task watches Vbus and starts the clamp process when the voltage reaches 28 V.
Regulator
Runs every millisecond, updates the simulated plant and sends Vbus, Iload and ClampGate to Traxcope.
LoadSim
Produces the repeating load-disconnection event that makes the bus voltage rise.
The application also contains an intentional intermittent failure. Every fourth load dump, the clamp response is delayed. Instead of responding normally, the application waits until Vbus reaches 33 V and then delays the clamp by another 20 ms. In the Scope View, the abnormal case rises to roughly 36 V before ClampGate becomes active.
Load disconnects, Iload falls, Vbus rises, the clamp activates in time and Vbus stays below the critical limit.
Every fourth event receives a delayed clamp response, Vbus crosses 33 V and the system exceeds its specification limit.
Automatically preserve the abnormal case without requiring continuous manual observation.
Step 1
Verify the behavior in Scope View.
Before creating a trigger, confirm that the application produces both expected and abnormal cases. The tutorial monitors three signals:
- Vbus: bus voltage, normally around 25.5 V.
- Iload: load current, which drops to zero when the load is disconnected.
- ClampGate: clamp activation state.
In a normal load dump, Vbus rises while Iload is zero, then ClampGate goes high before the voltage reaches 33 V. In the intentionally delayed case, Vbus continues upward to approximately 36 V before the clamp activates.
Why verify first? A trigger should represent a confirmed system condition. Scope View gives you the threshold, direction and timing evidence needed to define that condition precisely.
Step 2
Create the 33 V rising-edge trigger.
Once the abnormal event is visible, the trigger definition is direct. Select the connected demo target, use Vbus as the source variable and configure a Rising Edge condition with a threshold of 33 V.
Vbus crosses 33 V in the rising directionCreate a new trigger
Open Trigger Studio and add a new trigger configuration for the overvoltage event.
Select the source
Add a variable condition and select Vbus from the connected demonstration target.
Define the edge
Choose Rising Edge and enter 33 V as the threshold. A falling transition will not fire this condition.
Set the capture timing
Use 100 ms pre-trigger, 400 ms post-trigger and 1000 ms holdoff.
Complete the flow
Connect the condition node to the TRIGGERED output, then save the trigger configuration.
Arm and run
Arm the trigger and let the application continue. Traxcope captures the next matching abnormal event automatically.
Capture timing
Pre, Post and Holdoff answer different questions.
The trigger instant alone is rarely enough to diagnose a failure. The lead-up explains how the system entered the condition, while the response shows whether protection or recovery logic behaved correctly.
| Parameter | Tutorial value | Purpose |
|---|---|---|
| Pre-trigger | 100 ms | Preserves the activity before Vbus crosses 33 V, including the load disconnection and the beginning of the rise. |
| Post-trigger | 400 ms | Continues recording after the crossing so the delayed clamp response and voltage recovery remain visible. |
| Holdoff | 1000 ms | Introduces a quiet period before re-arming, which prevents a single event burst from producing repeated captures. |
The official Trigger Studio workflow also includes a Window value for correlating momentary conditions in compound AND logic. When two edge or event conditions cannot occur at the exact same timestamp, a small non-zero window defines how close together they must occur to count as one combined event.
Step 3
Review the failure across synchronized views.
After the trigger is armed, each Vbus crossing that matches the condition is added to the Captured Events list. The engineer no longer needs to watch the signal continuously or estimate where the anomaly occurred in a long recording.
Selecting a captured event navigates every synchronized Traxcope view to the same interval. Scope, Trace and Event views can therefore show the same failure window, using the exact pre-trigger and post-trigger limits from the trigger configuration.
- Scope View shows the voltage rise, clamp state and recovery.
- Trace View shows task and interrupt execution around the same timestamps.
- Event and log views preserve messages and markers in the same context.
- The capture history makes repeated occurrences available for comparison.
This synchronization is the practical benefit: the abnormal signal is not separated from the firmware activity that produced it.
Compound conditions
Capture long regulation events with two conditions.
The tutorial then creates a second trigger. Scope measurements show that the delayed regulation event lasts about 299 ms. The new goal is to capture cases where Vbus remains above 26 V and the Overclamp interval lasts longer than 200 ms.
Vbus > 26 V AND Overclamp duration > 200 msThis trigger combines a variable state with a marker-duration verdict:
- Add a variable condition for Vbus > 26 V.
- Add a marker condition for Overclamp duration > 200 ms.
- Connect both conditions so the TRIGGERED output is reached only when they are satisfied together.
In Trigger Studio, graph topology expresses the logic. Conditions connected in series form an AND path. Separate complete paths from Input to TRIGGERED form OR logic. This makes the condition readable as both a visual flow and an engineering statement.
Beyond this example
Trigger sources are not limited to variables.
The overvoltage tutorial uses variable and marker conditions, but Trigger Studio can evaluate several kinds of data that Traxcope already receives. Trigger evaluation runs on the host, so traced data can become a trigger source without adding separate trigger logic to the firmware.
| Source | Example conditions |
|---|---|
| Variable | Rising, falling or either edge; above or below a level; inside or outside a window. |
| Task | A kernel event occurs or a selected task is running. |
| ISR | An interrupt enters or exits, or an ISR remains active while another condition occurs. |
| Log | A message matches a pattern at or above a selected severity. |
| State machine | A state is entered or exited, or a specific transition occurs. |
| Marker | An interval starts or stops, remains active, or exceeds a duration limit. |
| Timing | No expected activity occurs before a timeout. |
| DSP | A frequency bin, band energy, dominant frequency, spectral mask, THD or harmonic level crosses a defined condition. |
Live and recorded data
Use the same trigger logic during capture or review.
Trigger Studio supports two practical contexts. In Live mode, the trigger evaluates the incoming stream and captures the condition when it occurs. In Review mode, the same logic can scan a loaded recording and locate every matching occurrence.
This distinction matters for long test sessions. A trigger can police a known critical condition live, or it can turn an overnight recording into a dataset that can be queried by runtime behavior. Captured matches remain available in the event list, and selecting one moves synchronized views to that interval.
Practical guidance
Build triggers around engineering questions.
- Start from observed behavior. Use Scope, Trace, logs or marker statistics to confirm the threshold and timing before defining the trigger.
- Choose edge or level deliberately. An edge captures the transition through a threshold. A level remains true while the signal stays above or below it.
- Keep enough pre-trigger time. The cause of a fault often appears before the threshold crossing.
- Size post-trigger time for the response. Protection, retry and recovery logic may execute after the initial fault condition.
- Use holdoff to control repeated firings. Set it long enough to separate individual system events.
- Use marker duration for timing budgets. It directly answers whether an instrumented interval exceeded its allowed duration.
- Add a Window for momentary AND conditions. Separate events rarely share an identical timestamp.
- Scope conditions to the correct probe. In multi-probe sessions, choose a specific source when the condition must belong to one board.
Video walkthrough
Watch the complete Trigger Studio setup.
Burak Emre Polat demonstrates the application behavior, creates both trigger configurations and reviews the synchronized capture in Traxcope.
Frequently asked questions
Trigger Studio basics.
Does a trigger stop the target firmware?
No. Trigger conditions are evaluated on the host from data already being traced. Live views can continue streaming while captured events are added to the event history.
Why use pre-trigger capture?
The threshold crossing identifies when the failure became visible. Pre-trigger data preserves the activity that led to it, which is often where the root cause begins.
What is the difference between Rising Edge and Above Level?
Rising Edge fires when a value crosses the threshold upward. Above Level represents the continuous state in which the value remains above that threshold.
Can one trigger contain more than one condition?
Yes. Conditions can be combined in the node graph. Series paths express AND logic, while separate complete paths express OR logic.
Can Trigger Studio search an existing recording?
Yes. Review mode scans recorded data with the selected trigger definition and adds each match to Captured Events for synchronized inspection.
Exclusive to Traxcope | Tutorial 10
Event-based firmware capture
Capture intermittent firmware failures with Trigger Studio.
Trigger Studio is a Traxcope-exclusive workflow for detecting a rare overvoltage event, preserving the activity that led to it and reviewing every synchronized view at the exact capture window.
Tutorial at a glance
The complete capture setup in four values.
The simulated 24 V bus-voltage variable.
Fire only when Vbus crosses the limit upward.
Keep the lead-up and the response in one capture.
Prevent repeated captures from the same short event burst.
The debugging problem
When the failure is known but its timing is not.
Intermittent firmware failures rarely wait for an engineer to open the right view. A signal may cross its limit once in hundreds of cycles, a task may exceed its timing budget only under a specific load, or a fault may appear only when two otherwise normal conditions overlap.
Continuous recording preserves data, but it can leave the engineer searching through a long timeline. Watching a live graph manually has the opposite limitation: the relevant moment can pass before it is noticed. A breakpoint is even less suitable when the behavior depends on real-time execution because stopping the target changes the system being investigated.
Available exclusively in Traxcope, Trigger Studio addresses this gap with event-based capture. You define the condition that represents the failure, arm the trigger and let the application continue to run. When the condition is met, Traxcope preserves the chosen interval before and after the event. The result is a focused capture with the surrounding runtime context still attached.
The central idea: do not wait for the rare fault and then search backward. Define the fault first, then let the capture come to you.
Tutorial scenario
A 24 V power system with an intermittent clamp delay.
Tutorial 10 starts from the T01 initialization project and uses the same FreeRTOS configuration introduced in the earlier FreeRTOS tutorial. The demonstration application models a 24 V power system with a load-dump event and an overvoltage clamp.
During normal operation, the simulated bus voltage stays near 25.5 V. Once every second, the application disconnects the load. Load current falls to zero and the bus voltage begins to rise. The overvoltage clamp should react before Vbus reaches the critical 33 V limit, then return the bus below 26 V.
Overclamp
The highest-priority task watches Vbus and starts the clamp process when the voltage reaches 28 V.
Regulator
Runs every millisecond, updates the simulated plant and sends Vbus, Iload and ClampGate to Traxcope.
LoadSim
Produces the repeating load-disconnection event that makes the bus voltage rise.
The application also contains an intentional intermittent failure. Every fourth load dump, the clamp response is delayed. Instead of responding normally, the application waits until Vbus reaches 33 V and then delays the clamp by another 20 ms. In the Scope View, the abnormal case rises to roughly 36 V before ClampGate becomes active.
Load disconnects, Iload falls, Vbus rises, the clamp activates in time and Vbus stays below the critical limit.
Every fourth event receives a delayed clamp response, Vbus crosses 33 V and the system exceeds its specification limit.
Automatically preserve the abnormal case without requiring continuous manual observation.
Step 1
Verify the behavior in Scope View.
Before creating a trigger, confirm that the application produces both expected and abnormal cases. The tutorial monitors three signals:
- Vbus: bus voltage, normally around 25.5 V.
- Iload: load current, which drops to zero when the load is disconnected.
- ClampGate: clamp activation state.
In a normal load dump, Vbus rises while Iload is zero, then ClampGate goes high before the voltage reaches 33 V. In the intentionally delayed case, Vbus continues upward to approximately 36 V before the clamp activates.
Why verify first? A trigger should represent a confirmed system condition. Scope View gives you the threshold, direction and timing evidence needed to define that condition precisely.
Step 2
Create the 33 V rising-edge trigger.
Once the abnormal event is visible, the trigger definition is direct. Select the connected demo target, use Vbus as the source variable and configure a Rising Edge condition with a threshold of 33 V.
Vbus crosses 33 V in the rising directionCreate a new trigger
Open Trigger Studio and add a new trigger configuration for the overvoltage event.
Select the source
Add a variable condition and select Vbus from the connected demonstration target.
Define the edge
Choose Rising Edge and enter 33 V as the threshold. A falling transition will not fire this condition.
Set the capture timing
Use 100 ms pre-trigger, 400 ms post-trigger and 1000 ms holdoff.
Complete the flow
Connect the condition node to the TRIGGERED output, then save the trigger configuration.
Arm and run
Arm the trigger and let the application continue. Traxcope captures the next matching abnormal event automatically.
Capture timing
Pre, Post and Holdoff answer different questions.
The trigger instant alone is rarely enough to diagnose a failure. The lead-up explains how the system entered the condition, while the response shows whether protection or recovery logic behaved correctly.
| Parameter | Tutorial value | Purpose |
|---|---|---|
| Pre-trigger | 100 ms | Preserves the activity before Vbus crosses 33 V, including the load disconnection and the beginning of the rise. |
| Post-trigger | 400 ms | Continues recording after the crossing so the delayed clamp response and voltage recovery remain visible. |
| Holdoff | 1000 ms | Introduces a quiet period before re-arming, which prevents a single event burst from producing repeated captures. |
The official Trigger Studio workflow also includes a Window value for correlating momentary conditions in compound AND logic. When two edge or event conditions cannot occur at the exact same timestamp, a small non-zero window defines how close together they must occur to count as one combined event.
Step 3
Review the failure across synchronized views.
After the trigger is armed, each Vbus crossing that matches the condition is added to the Captured Events list. The engineer no longer needs to watch the signal continuously or estimate where the anomaly occurred in a long recording.
Selecting a captured event navigates every synchronized Traxcope view to the same interval. Scope, Trace and Event views can therefore show the same failure window, using the exact pre-trigger and post-trigger limits from the trigger configuration.
- Scope View shows the voltage rise, clamp state and recovery.
- Trace View shows task and interrupt execution around the same timestamps.
- Event and log views preserve messages and markers in the same context.
- The capture history makes repeated occurrences available for comparison.
This synchronization is the practical benefit: the abnormal signal is not separated from the firmware activity that produced it.
Compound conditions
Capture long regulation events with two conditions.
The tutorial then creates a second trigger. Scope measurements show that the delayed regulation event lasts about 299 ms. The new goal is to capture cases where Vbus remains above 26 V and the Overclamp interval lasts longer than 200 ms.
Vbus > 26 V AND Overclamp duration > 200 msThis trigger combines a variable state with a marker-duration verdict:
- Add a variable condition for Vbus > 26 V.
- Add a marker condition for Overclamp duration > 200 ms.
- Connect both conditions so the TRIGGERED output is reached only when they are satisfied together.
In Trigger Studio, graph topology expresses the logic. Conditions connected in series form an AND path. Separate complete paths from Input to TRIGGERED form OR logic. This makes the condition readable as both a visual flow and an engineering statement.
Beyond this example
Trigger sources are not limited to variables.
The overvoltage tutorial uses variable and marker conditions, but Trigger Studio can evaluate several kinds of data that Traxcope already receives. Trigger evaluation runs on the host, so traced data can become a trigger source without adding separate trigger logic to the firmware.
| Source | Example conditions |
|---|---|
| Variable | Rising, falling or either edge; above or below a level; inside or outside a window. |
| Task | A kernel event occurs or a selected task is running. |
| ISR | An interrupt enters or exits, or an ISR remains active while another condition occurs. |
| Log | A message matches a pattern at or above a selected severity. |
| State machine | A state is entered or exited, or a specific transition occurs. |
| Marker | An interval starts or stops, remains active, or exceeds a duration limit. |
| Timing | No expected activity occurs before a timeout. |
| DSP | A frequency bin, band energy, dominant frequency, spectral mask, THD or harmonic level crosses a defined condition. |
Live and recorded data
Use the same trigger logic during capture or review.
Trigger Studio supports two practical contexts. In Live mode, the trigger evaluates the incoming stream and captures the condition when it occurs. In Review mode, the same logic can scan a loaded recording and locate every matching occurrence.
This distinction matters for long test sessions. A trigger can police a known critical condition live, or it can turn an overnight recording into a dataset that can be queried by runtime behavior. Captured matches remain available in the event list, and selecting one moves synchronized views to that interval.
Practical guidance
Build triggers around engineering questions.
- Start from observed behavior. Use Scope, Trace, logs or marker statistics to confirm the threshold and timing before defining the trigger.
- Choose edge or level deliberately. An edge captures the transition through a threshold. A level remains true while the signal stays above or below it.
- Keep enough pre-trigger time. The cause of a fault often appears before the threshold crossing.
- Size post-trigger time for the response. Protection, retry and recovery logic may execute after the initial fault condition.
- Use holdoff to control repeated firings. Set it long enough to separate individual system events.
- Use marker duration for timing budgets. It directly answers whether an instrumented interval exceeded its allowed duration.
- Add a Window for momentary AND conditions. Separate events rarely share an identical timestamp.
- Scope conditions to the correct probe. In multi-probe sessions, choose a specific source when the condition must belong to one board.
Video walkthrough
Watch the complete Trigger Studio setup.
Burak Emre Polat demonstrates the application behavior, creates both trigger configurations and reviews the synchronized capture in Traxcope.
Frequently asked questions
Trigger Studio basics.
Does a trigger stop the target firmware?
No. Trigger conditions are evaluated on the host from data already being traced. Live views can continue streaming while captured events are added to the event history.
Why use pre-trigger capture?
The threshold crossing identifies when the failure became visible. Pre-trigger data preserves the activity that led to it, which is often where the root cause begins.
What is the difference between Rising Edge and Above Level?
Rising Edge fires when a value crosses the threshold upward. Above Level represents the continuous state in which the value remains above that threshold.
Can one trigger contain more than one condition?
Yes. Conditions can be combined in the node graph. Series paths express AND logic, while separate complete paths express OR logic.
Can Trigger Studio search an existing recording?
Yes. Review mode scans recorded data with the selected trigger definition and adds each match to Captured Events for synchronized inspection.
Start writing here...