Articles.

Define the System and Acceptance Conditions First

Suppose a project uses an MCU or DSP, a three-phase inverter, current sensing, and position feedback to implement an industrial motor drive. The first document should specify motor type, bus-voltage range, sensors, load inertia, communication cycle, and permitted startup methods. Servo positioning accuracy, VFD speed range, and current limits cannot be combined into a single requirement to 'run stably'.

Turn every requirement into an observable criterion: under specified bus voltage, load, temperature, and command changes, record response time, peak current, steady-state error, or fault-shutdown time. Mark values that currently lack a basis as pending confirmation. The motor, sampling scale, and protection thresholds in a vendor demonstration project belong to its example conditions; they are not product specifications for new hardware.

Establish Signal Contracts with Explicit Units

First draw the path from command to power output: communication reception, command validation, state permission, reference limiting, control computation, modulation, and PWM taking effect. Then draw the feedback path: analog front end, ADC, offset correction, engineering-unit conversion, and angle and speed updates. Specify units, positive direction, update timing, and failure criteria for every interface.

For example, the interface must fix whether current_a means amperes or ADC counts, and whether speed means mechanical rpm or electrical Hz. When interrupts and background tasks exchange data, use complete snapshots or an explicit publication protocol to avoid reading a mixture of new and old values. volatile restricts certain compiler optimizations; it does not replace consistency design across execution contexts.

Separate Execution Paths by the Consequences of Failure

Closed-loop current control depends on sampling and PWM updates and belongs in a periodic execution path whose timing can be analyzed. Communication, parameter persistence, and slower diagnostics should run at separate rates. An RTOS can organize tasks, but hard real-time compliance still depends on worst-case execution time, preemption, critical sections, and hardware timing. A high-priority task alone does not guarantee a deadline. Each path should have an explicit execution period and owner.

Fast overcurrent protection should configure comparator, driver, or PWM fault-input paths according to power-device tolerances. C2000 Trip-Zone is one specific implementation; confirm output levels against the gate driver's active levels. Software fault handling latches causes and restricts restart; a background warning cannot replace fast shutdown.

Bring Up the System in Layers Rather Than Closing Every Loop at Once

First, with power output controlled, confirm clocks, pins, safe outputs, current offsets, and bus-voltage conversion. Then check PWM polarity, dead time, ADC trigger points, and encoder direction. Only after this evidence is established should angle alignment and closed-loop current control begin under low-energy, current-limited conditions. Add the speed loop, position loop, or application commands afterward.

For each layer, save the configuration version, test conditions, raw records, and pass criteria. If a closed loop oscillates, check sampling scale, phase sequence, angle, and output delay before discussing PI parameters. Unit tests can verify conversion and limiting logic; bench tests verify the actual execution chain. Neither replaces the other. When reusing the implementation with another motor, reconfirm parameters and protection ranges.

Verification Checklist: Preserve Evidence and Uncovered Boundaries

The acceptance table should link requirement IDs to test IDs and records, explicitly retaining unexecuted operating conditions as gaps. One successful rotation under a debugger establishes only the local conditions at that time. For each check below, provide the expected state, output behavior, and evidence file separately.

• Under specified supply and load conditions, check the units and positive directions of current, speed, position, and modulation outputs.
• Measure worst-case latency of periodic execution paths using a release build, covering communication bursts, diagnostics, and interrupt nesting.
• Use controlled injection to check sensor failures, communication timeouts, invalid parameters, and hardware-protection responses.
• Check output states after power loss, reset, and fault acknowledgment, confirming that the system cannot run unexpectedly without a new valid start command.

Draw a Complete Timeline First

Suppose center-aligned PWM executes current control once per full period, with compare values loaded through shadow registers at specified counter events. Mark ADC triggering, sample-and-hold, conversion completion, interrupt entry, computation completion, register writes, and actual loading on the timeline. Finishing a control-result write does not mean the power output is already using it.

C2000 ePWM can trigger the ADC at counter-zero, period, or compare events and offers different shadow-load options; exact features depend on the chip model. If loading occurs every half period, the computation window may also be only half a period. Do not infer 'the algorithm has 50 μs available' directly from 'PWM is 20 kHz'.

Work Backward from the Load Event to the Deadline

Define t_sample as the sampling-trigger instant and t_load as the load event intended to use that result. An example budget is: t_load−t_sample must exceed the sum of sampling and conversion delay, interrupt waiting, worst-case computation, write time, and margin. Fill each term in this inequality with measurements or datasheet constraints; average ISR duration alone is insufficient.

For example, the full period is 50 μs, but sampling and the intended load event are only 25 μs apart. If sampling/conversion takes 2 μs, waiting takes 3 μs, computation/writing takes 12 μs, and 3 μs is reserved, 5 μs remains. These numbers illustrate the method only. Missing a load usually retains the old output; whether the additional delay is half a period or a full period depends on configuration.

Also record feedback-data age separately: do the current and angle values for this cycle come from the same instant, and does the speed-filter output lag by several cycles? Finishing the algorithm before its deadline establishes only timely computation. If it always uses an outdated angle, significant high-speed error may still occur. The budget must therefore check both completion timing and data provenance and sampling timestamps.

Sampling Windows Must Also Meet Circuit Requirements

Sampling points are first constrained by the current-sensing topology. Low-side shunts and single-shunt reconstruction have their own valid conduction windows, and must avoid switching transients while allowing amplifier settling and ADC sample-and-hold time. Fixing the trigger at the period midpoint is not valid for every duty cycle; detect and handle invalid samples when windows become insufficient at high modulation indices.

TI's F2837xD ADC interface expresses the acquisition window in SYSCLK cycles while also requiring the device-specified minimum time. This unit must not be generalized to other MCUs. Sequential multichannel acquisition also introduces interchannel timing offsets. Additional filtering can reduce noise but increases feedback delay, which must be included in the closed-loop model.

Include Scheduling Interference in the Budget

List high-priority ISRs, interrupt-disabled intervals, shared buses, DMA, Flash wait states, and cache changes that may block the periodic path. Prohibit unbounded loops, dynamic allocation, and blocking logging in the control ISR. Use short, bounded synchronization when the background publishes setpoints. Whether persistence operations block instruction fetch depends on the specific chip. Remeasure the budget after changes to compiler optimization, memory layout, or math libraries.

In FreeRTOS Cortex-M3/M4-class ports using BASEPRI, smaller numeric values indicate higher interrupt priorities. ISRs above the boundary permitted by configMAX_SYSCALL_INTERRUPT_PRIORITY cannot call FromISR APIs. Priority representations in registers and library functions may also differ. These are rules for specific ports and must not be copied to Cortex-M0, C28x, or every MCU.

Verification Checklist: Measure the Worst-Case Path

An RTOS, average CPU utilization, and a single oscilloscope pulse width cannot individually establish real-time behavior. Measure sample-to-output delay separately from time spent inside the ISR, using the final optimization level, actual memory placement, and normal peripheral loads, and record overrun counts.

• Check the PWM counting mode, ADC trigger source, end-of-conversion flag, and shadow-load event.
• Use GPIO or hardware tracing to observe sampling events, ISR boundaries, and PWM updates together, checking for missed loads.
• Cover maximum communication traffic, interrupt nesting, parameter storage, and extreme duty cycles, retaining the longest latency.
• Inject computation overruns and invalid samples, verifying that old-output retention, stopping, or degraded-operation policies match the design.

State the Subject and Conventions First

This article uses a balanced three-phase PMSM, rotor permanent-magnet flux orientation, and amplitude-invariant transforms to discuss how firmware interfaces align. FOC is not a set of formulas that can be combined arbitrarily: phase sequence, current positive direction, coordinate rotation direction, and modulator inputs must agree. AC induction motors have separate models for flux establishment and slip; PMSM angle relationships cannot be copied directly.

Create a conventions table in the project: which terminals correspond to A/B/C, whether positive current flows from inverter to winding, which side defines the view for positive mechanical rotation, what the encoder's positive counting direction is, and whether the d axis follows rotor flux. Include units in variable names so the same angle does not mean radians in one module and a normalized revolution in another.

Connect Coordinates with Explicit Formulas

Under the balanced three-phase assumption ia+ib+ic=0, one amplitude-invariant Clarke form is iα=ia, iβ=(ia+2ib)/√3. This article uses the Park form id=iα cosθ+iβ sinθ, iq=−iα sinθ+iβ cosθ. Its inverse is therefore iα=id cosθ−iq sinθ, iβ=id sinθ+iq cosθ. Other conventions can be valid, but the entire chain must change together.

If a library uses power-invariant normalization, its d/q amplitudes differ from those here, and torque constants and limits must match. The simplest static checks are id=iα and iq=iβ at θ=0, and id=iβ and iq=−iα at θ=π/2. Then perform forward/inverse transform round trips and check error bounds, rather than first connecting a motor to see whether it rotates.

Likewise, specify the voltage interface: whether the modulator accepts volts, a ratio to bus voltage, or per-unit values, and how output duty cycles map to bridge arms. If a current controller outputs a correct value but another scaling convention scales it again, actual closed-loop gain changes. Concentrating these conversions at clear boundaries makes them easier to check than scattered correction factors across multiple modules.

Electrical Angle Includes Direction, Pole-Pair Count, and Offset

Under the PMSM assumptions above, electrical angle can be written as θe=wrap(p·s·θm+θoffset), where p is the pole-pair count, s maps mechanical-sensor direction, and the offset is determined by the actual flux-alignment relationship. A four-pole motor has two pole pairs; pole count must not be used directly as the multiplier. Speed conversion similarly follows ωe=p·s·ωm, while converting rpm to rad/s also requires multiplication by 2π/60.

Encoder zero does not inherently equal rotor-flux zero. Alignment should constrain current, duration, and mechanical-motion conditions: confirm feedback direction first, then determine offset. With sampling and execution delays, the angle needed for control may also involve predictive compensation. Measure delay first and handle it according to a model; do not hide speed-dependent errors by arbitrarily adding offset. Check continuity at positive and negative speeds and near angle wraparound, particularly guarding against jumps caused by subtracting unsigned counts.

The Physical Meaning of d/q Depends on the Motor

For a rotor-flux-oriented PMSM, q-axis current contributes to electromagnetic torque, while d-axis current changes the stator-current component along the flux direction. With this article's amplitude convention, a common model is Te=(3/2)p[ψf iq+(Ld−Lq)id iq]. For a surface-mounted motor with Ld≈Lq, id*=0 is often used in the normal base-speed region; torque then varies approximately with iq. This does not establish the same behavior for every motor.

Saliency in an interior PMSM makes the reluctance-torque term significant, and MTPA may require nonzero id. High-speed field weakening is also constrained by voltage, current, and demagnetization limits. Permanent-magnet flux does not disappear when id=0. Describing variables as 'id is flux, iq is speed' loses these boundaries; speed is usually handled by an outer loop that requests torque or iq.

Verification Checklist: Establish Consistent Conventions First

Verify transforms in pure software first, then confirm direction and angle on an energy-limited bench. Repeat the same checks after changing phase wiring, reversing encoder direction, or replacing a math library. Voltage, current, flux, and torque formulas must use matching normalization.

• Use zero angle, a quarter revolution, and a full angle sweep to verify forward/inverse transforms, amplitudes, and fixed-point overflow.
• Confirm interface conversions for pole-pair count, mechanical/electrical speed, rpm/rad·s⁻¹, and peak/RMS values.
• Under controlled low-current conditions, check the torque and feedback directions corresponding to a positive iq request.
• Check voltage limiting and anti-windup under reduced bus voltage, current limiting, and field-weakening boundaries.

Parameters Need a Lifecycle

Suppose a drive supports communication-based configuration, motor-parameter storage, and field fault queries. Its parameter table should include identifier, type, unit, range, default, write permission, effective timing, and version. Rated current, current-sampling scale, pole-pair count, and control gains differ in nature. 'Change the variable when a write command arrives' is insufficient to ensure predictable operation.

Separate configuration into states such as pending modification, validated, currently active, and persisted. Real-time paths read complete active snapshots; publish a related parameter group only after validating it as a whole. Changes requiring a stop take effect while stopped, while references permitted to change online must pass through limits or ramps. Communication replies should distinguish successful reception, validation, and actual application.

Validate Parameter Relationships and Storage Integrity

After individual range checks, validate combinations: the undervoltage recovery threshold must exceed the trip threshold, the overvoltage recovery threshold must be below the trip threshold, and software current limits and hardware protection must have a reasonable hierarchy. Current-measurement range, bus-voltage scale, and motor and inverter limits must all match. Thresholds in vendor user guides depend on example hardware and motors and should not be copied directly to another drive.

Stored records can carry a format version, length, sequence number, and integrity check, with dual slots or another commit protocol handling interrupted writes during power loss. On validation failure, return to a clearly defined safe configuration with startup prohibited; do not silently adopt default motor parameters that may not fit. CRC detects corruption; it does not establish that parameters suit the hardware or came from a trusted writer.

State Transitions Need Conditions and Actions

The operating flow can be modeled as initialization, standby, preparation, running, stopping, and fault lockout; these names are design examples only. For each transition, specify the trigger event, entry conditions, and actions. Run permission must check valid configuration, sensor status, supply conditions, and absence of active faults together. Receiving a start command does not mean PWM can be enabled immediately.

Speed reaching zero, PWM being inhibited, and machinery stopping safely are different criteria. Define deceleration, braking, and loss-of-control handling according to the servo or VFD load. State transitions must also decide how to clear integrators, trajectories, and command buffers so a restart does not inherit old outputs. An ordinary firmware state machine is not automatically equivalent to a certified functional-safety implementation.

Separate Active Faults, Latched History, and Recovery Permission

The fast protection path first inhibits output according to hardware requirements; software then records the first cause, time, state, and key sampled values. Slower abnormalities may use defined filtering, duration, and hysteresis to avoid repeated noise triggers. Fast events such as short circuits must not use slow debouncing merely to share an interface. Fault codes should also distinguish active conditions, latched events, and diagnostic history.

A fault condition disappearing only means the abnormality is no longer currently present; it need not immediately permit operation. ST's six-step SDK, for example, distinguishes a fault-in-progress state from a state awaiting acknowledgment. Fault clearing should check permitted recovery conditions and return to controlled standby. The application must explicitly define whether automatic retries are allowed, their count, and their interval; these must not be hidden in a flag-clearing function.

Verification Checklist: Cover Boundaries and Concurrency

Tests should observe state, PWM/enable outputs, parameter versions, and fault records rather than only communication return codes. Use controlled simulation or dedicated test conditions for hazardous faults, first verifying the injection method and expected protection path. Do not use an actual short circuit to prove software logic.

• Write boundary values, invalid combinations, and unsupported versions, confirming that rejection leaves the old configuration intact.
• Simulate interruption or power loss during parameter commit and storage, confirming that a restart never uses a partial record.
• Inject faults during startup, operation, and stopping while simultaneously sending start, stop, and fault-clear commands.
• Check the first fault, active bits, history, and post-acknowledgment state; verify that startup after recovery still follows explicit permission conditions.

Define Device-Side Responsibilities First

Suppose an MCU motor drive accepts host polling over a serial port, providing speed references, operating status, and parameter configuration. This article discusses the RTU device side; it is not a scheduling mechanism for a high-frequency current loop. Transactions on the serial link are initiated by the requester, and the device processes valid requests after receiving them. Broadcast write requests receive no response.

Modbus defines the data model and operations, RTU defines serial frame organization and checking, and RS-485 is a common electrical interface. Wiring, termination, biasing, isolation, and transmit/receive direction must be confirmed separately against hardware conditions. Having an RS-485 transceiver does not mean the Modbus protocol exists. First fix the station address, baud rate, parity, and allowed function codes, then check the electrical layer.

Pass Complete Frames to the Parser

Have the UART interrupt or DMA handle only byte reception, timestamps, and overflow reporting, leaving frame processing to a communication task. RTU separates messages with silent intervals: at low speeds, follow the 1.5- and 3.5-character-time requirements; above 19200 bit/s, the guide recommends 750 microseconds and 1.750 milliseconds respectively. A UART IDLE event alone does not guarantee the RTU interframe interval.

The parser should check minimum length, buffer bounds, CRC, and station address before reading function fields. Frames with CRC errors or addressed to other stations must not trigger parameter writes. On overflow, discard the current frame and wait again for a valid boundary; do not assemble trailing bytes into the next request. After half-duplex transmission, release the bus based on the actual shift-register-complete event, not merely DMA-transfer completion.

The Register Map Is an Interface Contract

The common documentation number 40001 is a holding-register reference convention; the starting address inside the message is zero-based, so 40001 must not be inserted directly into the address field. Device manuals should list function code, zero-based address, quantity, type, unit, scaling, read/write permission, and default together. Check the host software's address-display convention as well, avoiding both sides subtracting one independently.

Protocol registers are 16-bit. Within one register, the high byte is transmitted first. The product interface must explicitly define the arrangement of 32-bit values across two registers; do not assume floating-point and integer word order are the same. For operating-data reads, first copy a consistent snapshot and then encode the response, preventing the high and low speed words from coming from different control cycles.

Writes Require Validation and Commit

The recommended path is frame reception, request validation, candidate-value decoding, parameter checks, commit, and response generation. When checking function support, address range, requested quantity, and byte count, use range calculations that cannot overflow. Illegal functions, illegal addresses, and message data-value errors have distinct protocol exception semantics. Explicitly define how out-of-range product parameters are reported as well, rather than treating every error as a CRC failure.

The communication task first writes to a staging area; the control task accepts the entire parameter group at an agreed boundary, especially for related limits and gains. Do not write Flash or directly modify shared control-loop quantities in a serial interrupt. Define retry behavior for commands with side effects, such as persistence, startup, and fault reset. A master retransmission after timeout must not repeat a one-time action. The manual must also specify which completed step a successful response represents.

Verification Checklist

First replay fixed messages through an offline parser, then connect the serial link to verify timing, and finally check parameter commits on a controlled bench. Protocol responses and safe motor operation are two independent acceptance criteria.

• Replay normal reads/writes, boundary addresses, zero quantities, length mismatches, CRC errors, truncated frames, and receive overflows; confirm there are no out-of-bounds accesses or unintended writes.
• Test matching station addresses, other station addresses, and broadcast writes separately. Broadcasts must produce no response, while error counters must still explain packet losses.
• Use known 16-bit and 32-bit values to check addresses and word order, and check snapshot consistency during continuous polling.
• Measure transmit/receive turnaround, maximum response time, and control-task load; verify product behavior after retries, power loss, and communication timeouts.

Online Does Not Mean Enabled

Suppose you are implementing a CANopen servo or variable-frequency drive: the host can read parameters and see heartbeats, but the axis does not accept references. First record CAN-controller status, NMT state, drive state, and local faults instead of repeatedly sending start commands. The physical bus, communication services, and power control have different entry conditions.

NMT defines a CANopen device's communication behavior; CiA 402 defines a drive's functional behavior and operating modes. The two state machines answer, respectively, whether a class of messages can be exchanged and whether a class of drive commands can be accepted. NMT Operational does not automatically mean CiA 402 Operation enabled, and the latter cannot replace hardware-protection and safety-function decisions.

Connect Communication and Application Through the Object Dictionary

The object dictionary organizes communication parameters, application parameters, and process quantities by index and subindex. SDO accesses dictionary entries, while PDO carries process data according to mappings. On the device side, define each entry's type, length, permissions, range, mappability, and side effects before implementing read/write callbacks. Do not expose an entire C structure as an unconstrained network interface.

PDO mappings determine which object each byte corresponds to; variables cannot be inferred from packet-capture positions alone. SDO parameter writes and PDO updates may come from different execution paths, so shared-data consistency must be designed. Copy network inputs into command snapshots for consumption by the control task, and publish operating feedback as snapshots too. Locks or critical sections need explicit duration bounds to avoid blocking control interrupts.

Implement the Two Sets of State Transitions Separately

After initialization, a CANopen CC device enters Pre-operational and sends boot-up. SDO is permitted in that state, while PDO communication occurs only in NMT Operational. Stopped still has NMT and error-control behavior. Therefore, when the communication stack receives an NMT command, it must start and stop services according to state; it must neither discard every frame indiscriminately nor keep using stale PDO data.

CiA 402 requests transitions through Controlword and reports state through Statusword; their common object indices are 0x6040 and 0x6041 respectively. A drive may also change state itself because of an internal fault. The device must interpret control bits according to the state table and update state after local conditions are met. It must not mechanically report success on receiving a command, or let a message directly bypass power-stage preparation. During integration, distinguish the state field, mode-specific bits, and warnings in the statusword; comparing its entire value with a fixed constant is insufficient to determine drive state.

Operating Modes Determine How Commands Take Effect

'Supports CiA 402' does not mean support for every operating mode and optional parameter. First list the modes actually implemented, then define reference units, limits, mode-switch timing, and feedback meaning. Position, speed, and torque references have different interpretations; host and firmware must use the same interface definition. Debug records should include requested mode, actual mode, controlword, statusword, and reference sequence number.

Heartbeats reflect network-management state; alone, they do not establish that fresh control references are still arriving. The product must separately define drive actions and recovery conditions after RPDO timeout, CAN bus-off, NMT stop, and faults. Quick stop behavior depends on parameters and implementation; its name must not be interpreted as a hardware safety stop. During recovery, eliminate the fault cause first, then verify reset and re-enable paths.

Verification Checklist

Cross-testing communication states and drive states is more valuable than verifying only one enable sequence. The following are device-firmware verification suggestions, not CiA conformance certification.

• Verify power-on boot-up, SDO/PDO boundaries in Pre-operational, data exchange in Operational, and service behavior in Stopped.
• For every supported CiA 402 transition, record the prior state, controlword, internal conditions, and resulting state, covering rejected transitions and internal faults.
• Check dictionary types, permissions, PDO mappings, and responses for unsupported objects; verify that concurrent reads/writes cannot produce partially updated parameters.
• Inject stopped reference updates, heartbeat loss, bus abnormalities, and mode changes; check controlled stopping, error reporting, and recovery order.

Start at the Device Application Boundary

Suppose an MCU or DSP joins the network through an EtherCAT Slave Controller, with the communication stack handling states and mailboxes and local tasks handling sensors, control loops, and outputs. A master detecting the device establishes only that parts of the link and identity reading work; startup configuration, process images, and application updates still need separate confirmation. Record product identity, firmware version, ESI version, and master cycle first.

This article discusses devices supporting CoE. CoE means CANopen over EtherCAT and can provide an object dictionary and parameter access, but it does not simply move CAN frames into EtherCAT. Nor can every EtherCAT product be assumed to require CoE or CiA 402. If a drive uses CiA 402, its drive state must still be handled separately from EtherCAT communication state.

State Transitions Are Configuration Checkpoints

Init has neither mailbox nor process-data communication. Pre-Op permits mailbox access and is suitable for parameter and process-data configuration. Safe-Op can exchange process data and update inputs, while outputs generally retain a device-defined safe state. Before entering OP, the master must first supply valid output data. The device should check configuration during the relevant transitions and return a diagnosable state error on failure.

OP means process communication is operational; it does not establish that the motor is enabled, sensor data is valid, or the control algorithm meets its targets. Output handling must also consider local drive state, faults, and command validity together. Safe-Op is not functional-safety certification either: watchdog configuration and device implementation affect actual output behavior. During debugging, measure actual outputs instead of judging only by state colors in the master's interface.

Keep the Dictionary, ESI, and Process Image Consistent

CoE dictionary entries must describe type, length, access rights, and whether PDO mapping is allowed. Mailbox SDO suits parameter and diagnostic access; cyclic PDO carries process quantities. ESI, the online dictionary, PDO mappings, and firmware copy functions must agree. Enable dynamic mapping only when the device explicitly supports it. If firmware supports only a fixed layout, explicitly reject unsupported combinations.

Document the process-image layout in a checkable table, specifying each entry's offset, bit width, direction, and scaling, and validate total length. First assemble network-received outputs into a complete command snapshot for the control task to accept; publish feedback by the same principle. Do not rely on compiler structure padding happening to match the bus layout, or allow mailbox parameter changes to alter meaning midway through a control computation.

Synchronize Sampling and Execution Instants

A device may support FreeRun, SyncManager synchronization, or Distributed Clocks synchronization; whether DC is required depends on the device and selected operating mode. DC coordinates local clocks and events; it does not replace the control task's execution budget. First decide which events trigger sampling, command latching, computation, and output updates, then analyze phase and delay.

For drives, the arrival time of new process data is not necessarily when the control reference takes effect. Record local cycle counts, command sequence numbers, latch times, and computation-completion times to locate communication-to-control latency. Define output actions and recovery conditions after disconnection, process-data watchdog events, or synchronization faults. Re-entering OP must not automatically replay motion references from before the failure.

Verification Checklist

First verify the basic path with a fixed process image and low-risk outputs, then add dynamic configuration and synchronization modes. Master logs must correspond to device-side counters and timing records.

• Check identity and ESI; verify Init, Pre-Op, Safe-Op, and OP transitions and error causes individually, saving actual and requested states.
• Read/write dictionary boundaries, read-only entries, and unsupported entries; use known byte patterns to check PDO direction, offsets, total length, and scaling.
• In every supported synchronization mode, measure period, phase, and execution-completion margin, then add mailbox traffic to check for disturbance to control tasks.
• Inject disconnection, master stop, and data timeouts; check outputs, drive enable, fault reporting, and recovery, confirming that OP is not treated as the axis-enable condition.

Start with a Reproducible Problem Description

Suppose a drive intermittently exhibits reference jumps after communication load increases. Asking AI directly to 'fix the race condition' embeds an unproven cause in the task. Better input includes the symptom, expected behavior, reproduction steps, versions, frequency, and known limitations. Reference jumps may come from word order, snapshots, timeout recovery, or shared data; retain multiple explanations initially.

Record the firmware commit, toolchain, optimization options, board version, parameters, and message-replay files. If reproduction is unreliable, establish trigger conditions and a statistical window first, reporting attempt and failure counts. Do not declare a fix after one normal run, or combine results from different hardware and loads into one body of evidence.

Provide Sufficient, Sanitized Context

The minimum materials for AI should include relevant functions, call order, task or interrupt relationships, shared variables, and failure logs. Preserve data types, lengths, chronological order, and error codes while removing keys, device credentials, customer identities, and unrelated data. Do not upload sensitive code without authorization; sanitized snippets, interface descriptions, or synthetic messages can express the same problem.

State constraints explicitly: analyze first; do not change hardware protection, extend timeouts to hide errors, change protocol interfaces, or refactor unrelated modules. Require evidence, counterevidence, and the next discriminating experiment for each candidate cause. Firmware tasks should also specify the real-time budget and available hardware-test conditions.

Eliminate Hypotheses Through Experiments

First ask AI to identify observation points closest to where the abnormal value originates. For example, record received raw bytes, the decoded reference, the snapshot accepted by the control task, and the adopted sequence number together. If the message is correct but decoding is wrong, check mapping; if decoding is correct but the consumed value changes, check shared data and lifetimes. Change only one key condition in each experiment.

Logging itself changes timing. Synchronous printing in a control interrupt may create or hide the problem. Use capacity-limited event buffers, counters, or hardware timing measurements, and report lost records. For a version regression, Git bisect can narrow the range between known-good and failing commits. Skip versions that cannot be built or judged; do not force them into the known-good category.

Make the Fix Independently Reviewable

Once evidence supports a cause, request a minimal change: explain which condition changes, why it removes the failure path, and which behaviors may be affected. First establish a check that triggers the original issue, then run that same check after modification. Inspect actual changes with git diff and remove unrelated formatting changes. A model's explanation is not a compilation, execution, or bench result.

Host-side tests suit parsers, boundary calculations, and pure state transitions; target-hardware tests address interrupt timing, DMA consistency, control budgets, and output actions. Both require saved commands, versions, raw outputs, and results. If only host tests are completed, explicitly retain hardware-verification items. Do not let AI delete assertions, relax acceptance scope, or change expected results merely to pass tests without explaining why.

Verification Checklist

The final deliverable should be a traceable chain: symptom, reproduction, evidence, cause, modification, and verification. Conclusions cover only the conditions actually verified.

• Confirm that versions, hardware, and parameters are fixed, failure logs remain locatable, and reproduction files and test inputs are reusable.
• Check facts, inferences, and unknowns individually; every root-cause judgment must correspond to raw observations or a valid experiment.
• Review the diff scope, boundary conditions, concurrency, and real-time effects; check that no secrets were uploaded or protection bypassed without authorization.
• Exercise the original issue, adjacent boundaries, and necessary regressions; record passed, failed, and untested items, and retain a recoverable original version.