FluidNC项目中TMC驱动检测问题的分析与解决方案

问题背景

在FluidNC开源运动控制项目中，用户报告了一个关于TMC5160和TMC2130驱动芯片检测不稳定的问题。该问题主要出现在FluidNC 3.9.x及更高版本中，表现为驱动芯片随机无法被正确检测，而回退到3.8.3版本则能正常工作。

问题现象

用户在使用包含TMC5160或TMC2130驱动芯片的控制板时，会遇到以下典型错误信息：

[MSG:ERR: X Axis TMC driver not detected - expected 0x30 got 0x0]
[MSG:INFO: Y Axis driver test passed]
[MSG:ERR: Z Axis TMC driver not detected - expected 0x30 got 0xff]

这种检测失败的情况具有随机性，每次启动时不同的轴可能会随机失败。在某些情况下，所有驱动都能通过检测，但这种情况并不稳定。

技术分析

根本原因

经过开发团队的分析和测试，发现问题主要出在SPI通信的时序控制上，特别是与I2S输出引脚作为片选(CS)信号相关的时序问题。具体表现为：

1. 在FluidNC 3.9.x版本中，I2S输出引脚的时序控制发生了变化
2. 新的时序控制可能导致CS信号与SPI时钟之间的同步出现问题
3. TMC驱动芯片对CS信号的下拉时间有严格要求，不满足时会导致通信失败

验证过程

开发团队使用逻辑分析仪对通信信号进行了捕获分析：

1. 在3.8.3版本中，时序稳定，信号同步良好
2. 在3.9.4版本中，信号时序出现明显不同步现象
3. CS信号与SPI时钟之间的延迟不足，导致TMC芯片无法正确识别通信

解决方案

临时解决方案

对于需要立即解决问题的用户，可以采用以下方法：

1. 回退到FluidNC 3.8.3版本
2. 在配置文件中移除min_pulse_us参数
3. 使用I2S_STATIC代替I2S_STREAM引擎

根本解决方案

开发团队提出了几种可能的长期解决方案：

1. 增加CS信号延迟：在TMC2130Stepper.cpp中添加CS信号激活后的微秒级延迟

void TMC2130Stepper::switchCSpin(bool state) {
  digitalWrite(_pinCS, state);
  if (!state) {
      delayMicroseconds(10);
  }
}

2. 调整I2S输出延迟：修改i2s_engine.c中的等待计数参数

uint32_t wait_counts = timer_running ? FIFO_THRESHOLD + FIFO_RELOAD : 6;

3. 优化SPI通信频率：对于使用I2S引脚作为CS的情况，降低SPI通信频率至100kHz

相关影响

该问题不仅影响TMC5160驱动，同样会影响TMC2130驱动。此外，一些用户报告在解决TMC驱动问题后，SD卡功能也出现了异常，这表明可能存在更底层的SPI总线共享或时序冲突问题。

建议与最佳实践

对于遇到类似问题的用户，建议：

1. 首先确认硬件连接正常，特别是SPI总线的接线
2. 尝试不同版本的FluidNC固件，确定问题出现的版本范围
3. 使用逻辑分析仪捕获SPI信号，分析具体时序问题
4. 对于自行设计控制板的用户，考虑在硬件层面增加适当的信号延迟电路
5. 关注FluidNC项目的更新，及时获取官方修复方案

总结

TMC驱动检测问题揭示了嵌入式系统中精确时序控制的重要性，特别是在使用I2S引脚模拟数字信号时。该问题的解决不仅需要软件层面的优化，也需要开发者对硬件特性的深入理解。随着FluidNC项目的持续发展，这类底层通信问题将得到更完善的解决方案。