An Arduino application runs reliably while exchanging test values through EasyCAT, then stops at random after SimpleFOC motor control is added. The evidence does not establish Serial as the root cause. The stronger fault boundaries are shared SPI access, motor-control execution, electrical effects that begin when the driver is active, and loss of loop service time.
Define the fault boundary
| Observed condition | Engineering implication |
|---|---|
| EasyCAT exchanges gyroscope or generated test values successfully without SimpleFOC control. | The basic EtherCAT configuration and process-data mapping can operate. |
The failure appears after SimpleFOC, motor.loopFOC(), and motor control are added. |
Investigate the added SPI activity, execution load, motor driver, and power stage. |
| The stop occurs after variable run times. | Do not treat this as a confirmed configuration or baud-rate fault without capturing the state at failure. |
Serial prints only during setup in the shown programs. |
Changing the baud rate alone does not test the runtime EtherCAT or motor-control paths. |
The code uses EasyCAT chip select pin 7, an encoder chip select on pin 12, and, in the larger program, a pendulum sensor chip select on pin 11. Confirm whether these devices share one SPI peripheral and whether every inactive slave releases the bus correctly. The supplied evidence does not establish the board model, SPI transaction settings, or interrupt behavior, so SPI contention remains a hypothesis rather than a confirmed defect.
Separate Serial, SPI, and EtherCAT
Serial.begin(9600) configures the diagnostic serial port. It does not set the EtherCAT or SPI transfer rate in the shown code. A higher baud rate can reduce blocking when large amounts of text are printed, but these programs print only a short EasyCAT banner and initialization result during setup. Test Serial by removing all prints while leaving the EtherCAT and motor paths unchanged; if the stop remains, the baud rate is not the controlling variable.
EasyCAT communication is serviced by EASYCAT.MainTask(), while the magnetic sensor and EasyCAT interface both involve SPI. That concurrency is a more direct communication boundary to test. Confirm unique chip-select wiring, observe that inactive chip-select lines remain inactive during another device's transaction, and determine whether the libraries save and restore SPI configuration around each transaction.
Correct the loop-rate assumption
The comments describe an approximately 1 ms loop and a control update near 25 ms, but the code does not measure elapsed time. Both periods depend on the execution time of motor.loopFOC(), EASYCAT.MainTask(), sensor updates, and other library work.
The condition if (loop_count++ > 25) becomes true on the twenty-seventh pass after the counter is reset. It therefore represents a pass count, not a guaranteed time interval. Instrument actual elapsed time externally or with a lightweight timestamp, and verify that EASYCAT.MainTask() continues to execute at the required rate. Do not add continuous Serial logging during this timing test because the logging can change the behavior being measured.
Run a controlled isolation procedure
- Record whether
EASYCAT.Init()reportsinitializedorinitialization failed. If initialization fails, stop and correct EasyCAT recognition or chip-select wiring before analyzing the random runtime stop. - Run the existing EasyCAT-only test and confirm continuous input and output process-data exchange.
- Include SimpleFOC and initialize its objects, but keep the motor power stage inactive. This separates library initialization and SPI use from electrical effects produced by the motor driver.
- Add
motor.loopFOC()while continuing to callEASYCAT.MainTask(). Use GPIO state markers or an external trace rather than high-volume Serial output to determine which call is entered but not exited. - Enable
motor.move(targetVoltage)only after the preceding configuration remains stable. Begin with a controlled master command and verify the received value before applying it. - If failure starts only with the powered driver, inspect controller supply stability, grounding, SPI signal integrity, and reset behavior while the motor switches. The evidence does not identify which electrical mechanism, if any, is present.
- If failure starts before motor power is enabled, capture chip-select and SPI clock activity around the last successful EasyCAT and sensor transactions. Verify that EasyCAT and each sensor can operate individually before combining them.
Verify recovery and control behavior
A successful result requires more than observing that the Arduino no longer appears frozen. Verify continuous EasyCAT process-data updates, repeated execution of both motor.loopFOC() and EASYCAT.MainTask(), valid encoder updates, and a controlled response to MotorVoltage.
The first program calls motor.move(targetVoltage) only when MotorVoltage changes, while the reduced test calls it on each downsampled pass. Because the evidence does not specify SimpleFOC's required call pattern, preserve this difference as a test variable. Compare the two patterns without simultaneously changing SPI wiring, baud rate, or motor power.
FAQ
Does SimpleFOC interfere with Arduino Serial communication?
The evidence does not demonstrate direct interference. The shown code uses Serial.begin(9600) and prints only during setup, so remove those prints to test Serial independently before attributing the runtime stop to baud rate.
Why does EasyCAT stop after SimpleFOC is added?
The confirmed boundary is the addition of SimpleFOC motor control; the exact cause is unknown. Test shared SPI access, service time for EASYCAT.MainTask(), and electrical behavior when the motor driver is enabled as separate variables.
Is loop_count greater than 25 a 25 ms timer?
No. if (loop_count++ > 25) triggers on every twenty-seventh loop pass, and the elapsed time varies with the work performed by the FOC, EtherCAT, and sensor calls.