我们有一个完全托管在DA14580，这是一个SPI奴隶中心。我们有第二个DA14580作为SPI主机运行。其思想是从BTLE健康外围设备获取数据并将该数据传输到SPI主机。我们不能理解的是，为什么这种转移在一种情况下是稳定的，而在另一种情况下是不稳定的。
在稳定的情况下，当特征值更新指示发出信号时，在中央从机上接收测量。在这个回调中，我们对度量进行解码，将其序列化到大约32字节的缓冲区中，将其放入队列中，然后调用执行SPI传输的方法。传输读取队列中的数据，并将数据传输到主机。它从不失败。
在不稳定的情况下，度量被放置在队列中，但是调用传输的方法此时没有完成。中央处理器只是将数据排队并从特征指示回调返回。现在在arch\u main方法中，从回调返回后，将从while主循环中的rwip\u scheduler（）返回。在这个main while（）循环中，我们检查队列中是否有要发送的数据，如果有，我们调用执行SPI传输的方法。传输非常不稳定，经常导致死锁。在主机中SPI传输的定时中设置随机延迟可以提高成功的机会，但这也是不可靠的。一个逻辑分析器揭示了导线上的数据是正确的。
为什么会这样？我们试着观察这两种情况下的中断，它们是一样的。但是BTLE子系统肯定有什么东西在arch\u main while循环中调用SPI传输时破坏了它，但是如果在rwip\u scheduler（）处理的回调之一中调用，它就会受到某种程度的保护。当中央从机正在扫描时，简单回音命令的传输（将一组字节从主设备发送到从设备，然后再将这些字节发送回主设备）是不稳定的，但当中央从机连接到单个设备而不是扫描时是稳定的，这一事实进一步说明了这一概念，简单地等待外围设备发送测量值；换句话说，当BTLE子系统中没有任何事情发生时。
我们有几个DA14580的集合，所有这些集合上的行为都是相同的；因此这不是某个特定板的故障，而是DA14580作为一个整体特有的问题。
考虑到在处理由rwip\u scheduler（）触发的方法中的SPI传输时所观察到的稳定性以及其他时间的不稳定性，这个bug的一个潜在解决方法是创建我们自己的方法，该方法将由rwip\u scheduler调用，但我们不知道如何做到这一点。