实验证明，STM32F103的SPI响应时间是能在指令级别时间粒度感知到的

la45088d1

题目可能有点绕，说白了就是内核运行过快，进行了数据发送后立即访问SPI状态寄存器会因为SPI响应不过来导致状态读取失败。所以提交数据给SPI发送后，最好延迟几个指令周期再去访问SPI当前状态，然后可以知道SPI是否发送完了数据，是否出错啥的。:sweat:

我现在搞个DAC7311的工程，需要通过SPI接口写入数据从而改变DAC的输出。我的程序逻辑就是先开启SPI，然后写入要发送的数据到发送寄存器中，等待SPI状态寄存器的Busy位置0代表发送完成；然后再写一个数据，再次进行Busy位检查，最后关闭SPI接口，完成一次写DAC的操作。结果DAC输出不正常，用示波器一看好家伙，SPI的时钟只输出了8-9个脉冲就结束了，而且有时候8个，有时候9个。当时就怀疑是不是程序判断逻辑出错没有正确等待Busy置0完成当前数据发送就进行下一步操作了，检查了几遍，没发现问题。

后来又进行在线调试，直接在检测Busy的部分加断点，然后运行到该处分析状态。好家伙，直接得到了下图结果：


结果显示，如果全速运行到读取SPI_SR那一步，会发现读出来的数据全0，当时你可以通过Keil的外设窗口看到SPI_SR的寄存器是有TXE和RXNE置位的，证明这次读取出错了。然后如果在写入发送数据那一步增加一个断点，先运行到发送数据那一步，停止，然后再全速运行到读取SPI_SR那一步，可以看到，读出的值变成0x02了，正好SPI_SR中的TXE置位了，证明读取没有出错。

基于上面的实验，接着给写入数据到读取状态这一系列操作增加空指令延时，结果显示当NOP的数量为3时，全速运行到读取SPI_SR那一步数据仍然全0出错，当NOP数量大于4时，就可以得到非0的正确的结果，如下图所示：


于是，最终加了4个NOP，故障排除，DAC输出正常波形，示波器检查了SPI接口时序检测没有再出现任何问题。:victory:

la45088d1

当然，我觉得这个问题在使用C语言基于库编程的时候不存在，因为反复的函数调用返回带来的时间开销已经充当了写入-读取这个过程的必要延时。:titter:

la45088d1

inthsunshine 发表于 2021-9-17 16:37
stm32的SPI用了很多, 表示没碰到lz的问题,应该是没正确使用造成的异常结果

发送数据前，必须先检查TXE是否 ...

所以你根本没搞明白我在说什么。:lol:
检测标志位的前提是你必须正确读取标志位寄存器SPI_SR，我的实验结果就是刚写入发送的数据，立即去读SPI_SR寄存器是不行的，会直接读到全0的状态位，那你后面判断必然出错。
所以我在写入数据后加了延时，确保SPI准备好了才连续读取状态寄存器判断数据发送情况。至于我检测busy位的目的，我很清楚。
并且如果是我这种情况不加NOP，什么位的标志都读不出来，全是0，你仔细看我上面的图。

la45088d1

crazy0qwer 发表于 2021-9-17 15:40
1、如果你要连续写入数据，应该判断发送缓冲器空闲标志(TXE)而不是判断BUSY位。
2、BUSY位状态不止和是否发 ...

所以我通读了原版数据手册，发现在我的设置下读取busy就是可以达成数据不冲突的目的，所以没关系。
这次异常的原因是由于SPI_SR读取的异常导致程序运行错误，所以我才针对读取错误采取了措施，这才是我要表达的。并不是因为读到了标志位但使用了错误的依据，而是标志位根本读不出来。

la45088d1

fan.lu 发表于 2021-9-17 18:23
正解！
代码其实是while查询这些状态位而不是nop去等，因为不知道什么时候能ready ...

你想的有点多，NOP只是延时一个很小的时隙确保SPI_SR的结果是可以访问的，然后才进入一个while循环连续判断标志位的变化。否则的话，一进while马上读取寄存器就会得到全0的错误值，while一下就过了根本没起到作用。

la45088d1

inthsunshine 发表于 2021-9-18 07:50
仔细去看下官方的参考手册吧，从来没有提到发送完马上读SR会出错， 你的问题我也是第一次听说， 要真有这 ...

就因为官方手册没有才容易出问题。反正就那么几条指令，目的及其明确，你能看出什么原因导致这种诡异的问题吗?
另外你自己成功但是你的是C环境，加上随便调一个库函数损耗就快1，2us了，那肯定轮不到这种问题出现，所以这又引申出一个问题，就是你不能真的认为Keil这个编译器它真比你直接写指令好多少，很多编译结果你拿反汇编去检查都及其SB。
最后是DMA加SPI我又不是没搞过，一点问题都没有，我直接拿来刷屏幕，就是这个数据太少，所以没用SPI。

la45088d1

crazy0qwer 发表于 2021-9-18 09:52
1、手册明确说明不应用BUSY位来处理发送接收，BUSY位应该用来确定SPI是否全部发送完成。只有BUSY位=0才可 ...

事实上就是错了，你自己看我截的图，读到0x00时Keil的监视窗显示TXE=1，RXNE=1，这很明显读取结果不可能是0x00的。
另外现在程序把数据帧改成16-bit了，比起8-bit数据帧发一次测一次好太多。之前为了回避多次读取SPI_SR的问题直接改成16-bit所以只要发送一次就可以完成一帧传输，这个没写出来。但是依然没看见16个SCLK波形。证明还是状态判别出错，提前关闭了SPI。后面基于这个加了4个NOP就解决了，现在稳定没问题了，就不想去再次踩雷了。
不过第三条问题我可以明确告诉你，之前就是一个字节一个字节发的，共发送两次，第一次写入SPI_DR后，无延迟检测SPI_SR，等待Busy位置低SPI发完以后再写入第二次，然后再次立即循环检测SPI_SR的状态。断电测试显示写完以后立即读取，结果仍旧是0x00，哪怕Keil监视窗上面Busy闪过，TXE=1，RXNE=1.
而修改加了延时后，直接运行到状态检测循环后就出现回读数据为0x80，这时候恰好开始传输所以Busy=1，其它位为0，这样就没错。
至于SPI的信号的时序图，我已经反复了解了N次。之前我自己开荒使用DMA+SPI的时候，愣是几乎没参考已有历程，直接把SPI和DMA这个章节通读完，按照自己理解写的一个正确的程序，所以我觉得我对SPI常用的一些功能特性还是比较熟悉的，包括你说的那些信号建立流程。

la45088d1

crazy0qwer 发表于 2021-9-18 10:00
忘了说了，你固定加4个NOP再去读取SR判断。
有兴趣的话你可以用控制变量法测试下：最低SPI速率，最高SPI速 ...

有道理，闲着的时候试试，也算是侧面印证问题。:victory:

la45088d1

2545889167 发表于 2021-9-18 10:08
所以似乎用te位来判断就没这个问题

可是SPI_SR如果在写入数据那一瞬间开始计时，要延时几个周期的才出正确状态信息的话，无论检测那个位似乎都不怎么行哎。毕竟BSYy和TXE都在里面。不过根据分析，确实TXE比起BSY建立速度更快一些。因为TXE在缓冲区完成数据写入后很快就检测到了非空，立即置位，然后再把数据搬到发送移位寄存器后BSY才开始置位。