SPI GTL僵局

嗨mt_dialog，

Thanks for your reply. I am well aware of the flow_on/flow_off principle, I have read through UM-B-013 carefully. It is worth clarifying that I used the source code provided in the proximity reporter example from SDK5 (for both the host and the DA), which is why the flow control mechanism is (or should be) properly implemented. The problem I'm having is not related to the flow control mechanism and is even addressed in section 6.2.3 of UM-B-013:

To prevent the event of simultaneous transmissions from both master and slave(i.e. the master
sends the 0x05 start byte to begin the transmission of a message and the slave at the same time
sends a flow off byte to subsequently transmit another message),主acknowledge the
从站的可调整请求。

突出显示的示例正是我遇到的问题：主师愿发送消息（0x05），从而想要发送流关闭字节。它继续：

To do so, when the master detects DREADY to be active, it sends an
确认字节（ACK，选择为0x08）以通知奴隶可以继续发送
flow off byte (or any other data). This functionality is shown in Figure 3. On any DREADY rising edge,
主人必须承认它检测到它并使从设备能够发送数据。If the
Master不承认已升起的升高边缘，从而等待芯片选择线
inactive (which will indicate that the master has finished sending the message), activate DREADY
again, and wait for the acknowledgement to proceed to transmit.

However, the behaviour described above (bold) doesn't seem to be implemented on the DA side (see spi_hci.c):

BOOL SPI_HCI_FLOW_OFF_FUNC（void）
{
uint8_t tmp;
// First check if no transmission is ongoing
if（（spi_cs_getf（）== 0））
{
return false;
}
NVIC_DisableIRQ(SPI_IRQn); // Disable SPI interrupt to CPU
spi_dready_high(); // Assert dready to request transmit
do {
spi_wait_for_transfer(); // Wait for SPI transaction from SPI master device
tmp = spi_rxtxreg_read(); // Get byte from SPI
} while (tmp != DREADY_ACK); // If DREADY is not acknowledged, try again
[...]
}

The code above first checks if a transmission is ongoing,THEN它断言了树脂，then它无限期地等待SPI转移（或DREADY_ACK BYTE）。此行为不对应：

如果主设备不确认已上升沿，则从设备等待，直到芯片选择行处于非活动状态（这将指示主服务器已完成发送消息），再次激活开关，并等待确认以继续传输。

Let's look at the uC (host) side: Section 6.2.3 also states that

On any DREADY rising edge, the master has to acknowledge that it detected it and enable the slave device to send data.

The code from spi_hci_msg.c looks like this:

空白spi_send_hci_msg (uint16_t大小,uint8_t * msg_ptr)
{
uint16_t i;
// disable dready interrupt
nvic_disableirq（gpio0_irqn）;
// Polling DREADY to detect if data is being received
while(GPIO_GetPinStatus(SPI_GPIO_PORT, SPI_DREADY_PIN));
spi_cs_high（）;//关闭CS.
spi_cs_low（）; // Open CS
spi_access（0x05）;
[...]
}

The codeFIRST禁用所打断,thenIT调查减少，then它提取SPI芯片选择线路低。如果在中断禁用后的变量高，则UC将无限期地等待1，再次降低，并且将不需要提供可排除的IRQ请求。此外，CS线不会阻止这种情况发生，因为它在停用减速中断后被拉低。

我在这里错过了什么？

对不起长篇帖子，但我想确保我被正确理解。

Cheers!

嗨mt_dialog，

yes, you got it exactly right. In the attached image you'll find 4 signals:
1. SPI CLK (yellow)
2. SPI MISO（蓝色）
3. SPI CS（粉红色）
4. DREADY (green)
My scope only has 4 channels, so I couldn't capture the MOSI line.

在屏幕截图的开头，您可以看到flow_off通信：2个spi字节，包含dready_ack和flow_on字节。之后，主机启动传输（注意，在Orteady处于非活动状态时，CS行如何变为低电平）。在此（成功）传输之后，从站断言了减排信号（因为它想要发送Flow_off消息），并且主服务器也希望发送消息并将CS线路低。（为了更好的可视化，我搬了spi_cs_low（）代码行之前while（dready_get_status（））;. Otherwise you wouldn't see the CS line being pulled low.) Notice how both DREADY and CS are asserted (CS low, DREADY high) at almost the same time, but no subsequent SPI communication is visible. That is when the deadlock happens.

Thanks for your help!
mabraun

嗨mt_dialog，

感谢您的回复。在我当前的设置中，我能够调试双方，这就是为什么我知道双方都确实被困在spi_send_hci_msg（）和spi_hci_flow_off_func（）中。

我附上了4个屏幕捕获。我捕获了所有5条信号线（全部显示在紫色），按以下顺序：CLK，MOSI，MISO，CS，Dready。此外，我使用协议分析器来解释MOSI和MISO线，以蓝色显示在屏幕截图上。总线1对应于MOSI，BUS2到MISO。

1.png：关于有问题的序列的总体观点导致死锁。

2.png:放大鉴于流动序列。Dready很高，主机确认它（0x08）和从站发送Flowon字节（0x06）。

3.PNG：Zoomed-in view of the first byte sent by the Master, marking the beginning of a message (0x05).

4.png：静电鉴于主设备发送的消息结束（CS被拉高）。之后，发生死锁：从奴隶想要发送流程（开始通过断言有条件），Master想要发送下一条消息。请注意：违反我以前的帖子，我做了不是move thespi_cs_low（）代码行之前while（dready_get_status（））, which is why you cannot see the CS line being pulled low. This is the original code behaviour. The problem, however, remains the same: The master is stuck in spi_send_hci_msg(), waiting for the DREADY signal to go low. The slave is stuck in spi_hci_flow_off_func(), waiting for an SPI transfer.

Please let me know if you need any additional information.

Thanks for your help,
mabraun

对此有任何更新？您是否能够提供5-Wire SPI协议的固定实施？

Thanks,
mabraun

嗨mt_dialog，

thanks for your update, that is great news. Please keep me posted.

Regards,
mabraun