STM32
直播中

英雄孤寂

11年用户 1163经验值
私信 关注
[问答]

STM32F4作为SPI从机,主机发送完数据后,从机没有正确进入中断的原因?

NXP的1176作为主机,STM32F405作为从机,通信波特率为8.3MHz左右。cubeMX配置如下,开启了SPI中断。

每次进入HAL_SPI_TxRxCpltCallback(),都通过IO输出一个脉冲信号,如下图第二行所示。第一行为定时器6溢出回调函数的脉冲,第四行是SPI时钟信号。可以从图中看出,第四个时钟信号结束后,没有触发HAL_SPI_TxRxCpltCallback。且定时器中断在188.54ms处停止触发,一直到189.7ms处,HAL_SPI_TxRxCpltCallback出发后才恢复。又因为所配置的SPI中断优先级高于定时器中断优先级,我推测,由于某些原因导致通信结束后,SPI中断阻塞了。

但是我没有任何解决思路,请各位帮忙,不胜感激!如果提问有任何不完善,请提示我补充信息。




回帖(2)

陈逸群

2024-5-27 15:18:32
可以大致估算一下时间,中断频率不到一个微秒,应该是响应不过来。
举报

dplion5

2024-5-27 17:51:52

1. 首先,检查SPI中断配置是否正确。确保在CubeMX中正确配置了SPI中断,并在初始化代码中启用了中断。

2. 检查SPI中断优先级设置。确保SPI中断优先级高于定时器中断优先级,以便在SPI通信完成后能够正确触发中断。

3. 检查SPI时钟配置。由于通信波特率为8.3MHz,需要确保SPI时钟配置正确,以便从机能够正确接收数据。

4. 检查SPI从机的NSS(片选)信号。确保NSS信号在通信过程中正确地被拉低和拉高,以便从机能够正确识别通信开始和结束。

5. 检查HAL_SPI_TxRxCpltCallback()函数实现。确保在该回调函数中正确处理了SPI通信完成后的相关操作,例如清除中断标志位等。

6. 检查是否有其他中断或任务阻塞了SPI中断。由于您提到定时器中断在某个时间点停止触发,可能存在其他中断或任务影响了SPI中断的正常触发。检查中断优先级设置,确保没有其他中断或任务阻塞了SPI中断。

7. 使用调试工具(如ST-Link)逐步调试代码,观察SPI通信过程中的寄存器状态和变量值,以便找到可能的问题所在。

8. 如果以上方法都无法解决问题,可以尝试更新STM32F4的固件库和CubeMX版本,以确保使用的是最新且经过测试的版本。

举报

更多回帖

发帖
×
20
完善资料,
赚取积分