你好,
我操作一个DA14580外部处理器的配置。这是由加州大学(SPI主)使用GTL几十种SPI协议。我不停地跑进死锁的问题。当流媒体数据在祝福(因此很多加州大学和DA)之间的交通,我遇到一个州DA和加州大学想同时传输。更具体地说,DA卡住的spi_hci_write_func ()函数。它所信号高并等待一个SPI驱动传输(spi_wait_for_transfer ()):
…
spi_dready_high ();/ /维护所请求传输
{做
spi_wait_for_transfer ();/ /等待SPI事务从SPI主设备
…
然而,加州大学试图在同一时间发送消息和卡住spi_send_hci_msg ()所信号功能,等待去低:
…
/ /禁用所打断
dready_irq_disable ();
/ /轮询所检测,如果数据被接收
而(dready_get_status ());
…
以下情况:
——加州大学禁用所打断,就在DA断言所信号。
——所信号是高,但没有中断触发加州大学。
——相反,加州大学所信号去等待低。
——所信号不会低,由于DA是等待一个SPI传播。
- - >死锁
我想知道协议打算如何避免遇到上述僵局。从样子没有机制,防止这种情况。
谢谢!
mabraun
编辑:试图使问题更全面的描述
设备:
嗨mabraun,
有一个序列通过SPI总线传输数据信号和数据交换的设备不仅所为了防止这种情况,还有flow_on flow_off数据前应交换两个设备可以通过SPI总线传输数据。你可以看看嗯- b - 013为了检查详细的协议。有一个特定的程序主人跟奴隶之前,反之亦然为了避免这种僵局,主传输之前应该检查如果奴隶可用(如果从奴隶是一个流的最后一条消息发送字节)之前调用spi_send_hci_msg()和禁用中断。
由于MT_dialog
嗨MT_dialog,
谢谢你的回复。我深知flow_on / flow_off原则,我已经仔细阅读嗯- b - 013。值得澄清的是,我用了接近记者从SDK5示例中提供的源代码(主机和DA),这就是为什么流控制机制是(或应该是)正确实施。我的问题是不相关的流控制机制,甚至在部分6.2.3嗯- b - 013:
高亮显示的例子正是我经历的问题:主人想要发送消息(0 x05),奴隶想发送流字节。它仍在继续:
然而,上述行为(粗体显示)似乎并不在DA端实现的(见spi_hci.c):
bool spi_hci_flow_off_func(空白)
{
uint8_t tmp;
/ /首先检查如果没有正在进行的传输
如果((spi_cs_getf () = = 0))
{
返回错误;
}
NVIC_DisableIRQ (SPI_IRQn);/ /禁用SPI中断CPU
spi_dready_high ();/ /维护所请求传输
{做
spi_wait_for_transfer ();/ /等待SPI事务从SPI主设备
tmp = spi_rxtxreg_read ();/ /从SPI得到字节
}(tmp ! = DREADY_ACK);/ /如果所不承认,再试一次
[…]
}
上面的代码首先检查如果传输正在进行,然后它声称所行,然后它等待一个无限期SPI转让(或DREADY_ACK字节)。这种行为不符合:
让我们看看加州大学(主持人):部分6.2.3也指出
spi_hci_msg的代码。c是这样的:
空白spi_send_hci_msg (uint16_t大小,uint8_t * msg_ptr)
{
uint16_t我;
/ /禁用所打断
NVIC_DisableIRQ (GPIO0_IRQn);
/ /轮询所检测,如果数据被接收
而(GPIO_GetPinStatus (SPI_GPIO_PORT SPI_DREADY_PIN));
spi_cs_high ();/ /关闭计算机
spi_cs_low ();/ /打开计算机
spi_access (0 x05);
[…]
}
的代码第一个禁用所打断,然后这对所调查,然后它把SPI芯片选择线低。如果所高后中断禁用,加州大学将无限期地等待所所硬中断请求优先级别再低,请求将不会提供服务。同时,CS行不防止这种情况的发生,因为它是拉低处于待发状态后,所中断。
在这里我丢失的东西吗?
对不起,长文章,但我想确认我理解正确。
干杯!
嗨mabraun,
请原谅我如果我错了,你已经注意到,当有一个正在进行的事务从主,所以奴隶发送流量,和主发送(为了承认它的存在,所以主人准备发送数据和禁用IRQ immidiatelly奴隶问题后flow_off为了发送数据,所以所销得到高当时CS是禁用的(高所以躲避的CS检查spi_cs_getf()函数)所以来被高主卡在轮询程序和奴隶阻塞、等待(永远不会从主来的消息。
你经历过这种问题在您的应用程序,如果你做了,你有捕获的SPI事务?
由于MT_dialog
嗨MT_dialog,
是的,你找到了正确的做法。在附上的图片,你会发现4的信号:
1。SPI CLK(黄色)
2。SPI味噌(蓝色)
3所示。SPI CS(粉色)
4所示。所(绿色)
我的范围只有4通道,所以我不能抓住莫西人。
一开始的截图可以看到flow_off交流:2 SPI字节,包含DREADY_ACK FLOW_ON字节。之后,主发起传输(注意CS直线低而所不活跃)。(成功的)传播之后,奴隶断言所信号(因为它想发出一个flow_off消息),以及主想传达一个信息,把CS线低。(为更好地可视化我搬
spi_cs_low ()代码行之前而(dready_get_status ());。否则你不会看到CS线被拉低。)注意所和CS都断言所高)(CS低,几乎在同一时间,但没有后续SPI通信是可见的。这是当死锁发生。谢谢你的帮助!
mabraun
嗨mabraun,
我检查与支持团队,他们能告诉我,这种情况可能会发生,没有超时或任何其他机制,防止580发送命令而主机就开始发送数据流僵局似乎可以发生,很少但它的可能。因为我们从来没有ecountered这种问题,在操作SPI你能确保这个僵局是肯定的原因拖延你的系统,你能提供一个更完整的捕捉你的信号,为了确保0 x05离开宿主(莫西人信号)或如果你能调试,你确认这就是代码困在双方(spi_send_hci_msg()和spi_hci_flow_of_func ()) ?
由于MT_dialog
嗨MT_dialog,
谢谢你的回复。在我目前的设置我能调试双方,这就是为什么我知道双方确实是困在spi_send_hci_msg()和spi_hci_flow_off_func ()。
我附上4更多的屏幕截图。我捕获了所有5个信号线路(所有显示在紫色),按照以下顺序:时钟,莫西人,味噌,CS,所。此外,我使用一个协议分析器解释莫西人和味噌,蓝色的屏幕截图所示。公共汽车1对应于莫西人,Bus2味噌。
1. png:总体视图序列导致死锁问题。
2. png:猪肉的放大视图序列。所高,主承认它(0()和从发送FlowOn字节(0 x06)。
3. png:放大视图的第一个字节发送的主人,这消息(0 x05)的开始。
4. png:放大视图发送的消息的结束主拉高(CS)。之后,发生死锁:奴隶想发送FlowOff(通过断言所)开始,主人想要发送下一条消息。请注意:在与我以前的帖子,我做到了不移动
spi_cs_low ()代码行之前而(dready_get_status ()),这就是为什么你不能看到CS线被拉低。这是原始代码的行为。然而,问题仍然是相同的:主是困在spi_send_hci_msg(),等待所信号低。奴隶是困在spi_hci_flow_off_func(),等待一个SPI转移。请让我知道如果你需要任何额外的信息。
谢谢你的帮助,
mabraun
任何更新吗?你能提供一个固定的几十种实现SPI协议吗?
谢谢,
mabraun
嗨mabraun,
当时的问题是提出变更请求,到目前为止,我们有一个可能的解决方案,以克服这个僵局,但要花一些时间来对其进行测试和评估任何问题或限制。我将会有更多的在这星期或下星期,我将让你知道。
我们很抱歉给您带来不便。
由于MT_dialog
嗨MT_dialog,
谢谢你的更新,这是好消息。请与我保持联络。
问候,
mabraun