項目的代碼測試完成之后，準備收尾時，出現了問題。清除掉開發過程中用來調試的print打印之后，zephyr_polling 的 HCI 突然不能正常工作了，之前測試可用的 zephyr_polling 中的各個例程都不再能運行。

這個時候是去掉了 print 打印的，不能從日志找問題。經過一個一個嘗試之后定位到了 SPI 接收操作完成之后的一個 print。將其去掉之后，芯片運行會宕機，但若是替換為一個 2 ticks (即2ms)的時延，例程都能正常運行。

但是顯然不能這樣處理這個問題，這樣一是治標不治本 (只是在這個環境下避免了時序問題的發生，當條件改變，問題還可能出現)，二是影響性能。

于是使用這個(不太好用的)邏輯分析儀開始尋找問題。

1.是否接收header發送的太頻繁

先考慮問題是否出在輪詢接收，發送 header 過于頻繁，導致芯片down。

根據邏輯時序圖，很多地方都是發起接收之后直接讀取芯片的待發數據大小。而此時芯片并不一定準備好了做接收，讀到的數據大小很大，導致重復多次地讀取無用 byte。

官方例程里沒有這個問題是因為接收時中斷調用的，芯片那邊主動要求接收數據，一定準備好發送了。輪詢的話則應該等待芯片做好準備，拉高irq線再發送recv_header

處理：

在接收操作發送 header 前加入 !IsDataAvailable() 校驗，確認芯片準備好了再發 header 確定要接收的數據量。

加入判斷機制后大大減少了啟動用時，提高了效率。

但是去掉print芯片還是down了。

2.是否是拉高cs_pin后irq_pin響應太慢

考慮是否是拉高cs后irq_pin響應太慢

觀察時序圖發現，MCU 拉高 cs 希望發送數據之后，過了較長一段等待時間后 irq 才拉高進行 header 傳輸。

測試這種情況：cs 拉高再拉低，等待較長一段時間才 irq 拉高，此時傳輸數據，芯片并沒有 down：

3.是否不能在發送header之后同時收發

在接收處加入校驗后的代碼，去掉 print 芯片還是 down 了。觀察其最后的時序，發現其發送了發送 header 之后，同時進行了收發，然后 down 了。

沒有delay 發送接收碰撞 后續芯片 down 了， spi 通信失敗：

并且，反復測試之后，芯片都是在這一次傳輸之后宕機。這里發送的命令010cfc032c0101是關閉芯片自帶 host。同時傳輸的是 04ff03:01:000106 廠商事件包，應該是一個 6 字節的心跳包。

最后的那一個 06 是因為 host 要傳輸的命令是 7 個字節，最后有個隨機的電平。協議棧不會對芯片的特殊廠商事件包進行處理，即使被塞入接收隊列，最后協議棧處理的時候也會將其丟棄。

考慮是否不能同時收發。對比觀察正常的收發的時序。

帶 2 ticks delay 的接收

對比發現，正常的工作的傳輸并不會出現收發同時的情況。

拋開這個宕機問題不談，在發送的事務流程中，對于傳輸數據過程中芯片發過來的數據是直接丟棄的，而這將導致丟包。雖然這里丟失的是廠商事件包，本來就不會對其處理，但是處于普適性應該將其糾正。

解決同時收發的問題

觀察時序圖發現，發送 header 之后不進行數據傳輸時被芯片允許的。嘗試在實際發送之前檢查 send_header 響應中接收緩沖區數據量，如果不為 0，結束當此發送流程，先做一次完整接收，并將接收到的數據塞到接收隊列里，再重新發送 send_header (使用while循環，直到待接收數據為0)，繼續當前數據的發送。

直接在 send_header 傳輸完成之后加入判斷，進行一次接收：

/* Read header */
rt_spi_transfer(ble_spi, &header_master, &header_slave, HEADER_SIZE);
rx_bytes = (((uint16_t)header_slave[2])< 8) | ((uint16_t)header_slave[1]);
uint16_t byte_count = (header_slave[4] < < 8)| header_slave[3];
if (byte_count > 0) 
{
    hci_driver_init_loop();
    result = -2;
}
else
{
  if(rx_bytes >= size)
  {
    /* Buffer is big enough */
    rt_spi_transfer(ble_spi, buffer, &read_char_buf, size);
  }
  else
  {
    /* Buffer is too small */
    result = -2;
  }
  /* Release CS line */
  rt_pin_write(hci_config.cs_pin_num, PIN_HIGH);
}

測試發現并不行，這時想起我沒拉高 CS 結束這一次發送傳輸事務就直接啟動了一次接收，肯定會出錯。加入這一句：rt_pin_write(HCI_TL_SPI_CS_PIN, PIN_HIGH);。

但加入后仍然不能正常使用。發送超時了，也就是在發起接收的時候， cs 拉低之后，irq 一直沒有拉高

| /

RT - Thread Operating System
/ | 5.0.1 build Sep 9 2023 21:50:28
2006 - 2022 Copyright by RT-Thread team
do components initialization.
initialize rti_board_end:0 done
initialize stm32l4_hw_lptim_init:0 done
initialize finsh_system_init:0 done
msh >zephyr
zephyr_polling_init
bt_init_hci_driver
SPI_init_process device_name: spi10, spi_name: spi1, rate: 1000000, databits: 8, LSB_MSB: 1, Master_Slave: 0, CPOL: 0, CPHA: 1
SPI_init_process cs_pin_num: 1, irq_pin_num: 0
hci_driver_open, SPI_config_finish
I: (bt_hci_core)hci_init():3230: work start.
msh >SPI Send timeout 101
E: (bt_hci_core)hci_send_cmd():2928: Unable to send to driver (err -1)

查看時序圖：

發現后續irq_pin直到超時了都沒動一下，懷疑是前一次的發送流程沒有被芯片認定結束。

經過一系列嘗試和測試之后，發現要想結束當次發送流程，需要將 cs 拉高一定的時間，才能讓 chipset 覺得這次發送完了：

if (byte_count > 0) {
    /* Release CS line */
    rt_pin_write(HCI_TL_SPI_CS_PIN, PIN_HIGH);
    /* to end the send, we need a delay */
    rt_thread_delay(1);
    hci_driver_init_loop();
    result = -2;
}

雖然這里引入了時延，但是收發撞到一起的情況屬于特殊情況，對于整體的性能影響不大。

修改后芯片down掉的問題得到解決：

| /

RT - Thread Operating System
/ | 5.0.1 build Sep 9 2023 21:50:28
2006 - 2022 Copyright by RT-Thread team
do components initialization.
initialize rti_board_end:0 done
initialize stm32l4_hw_lptim_init:0 done
initialize finsh_system_init:0 done
msh >zephyr
zephyr_polling_init
bt_init_hci_driver
SPI_init_process device_name: spi10, spi_name: spi1, rate: 1000000, databits: 8, LSB_MSB: 1, Master_Slave: 0, CPOL: 0, CPHA: 1
SPI_init_process cs_pin_num: 1, irq_pin_num: 0
hci_driver_open, SPI_config_finish
I: (bt_hci_core)hci_init():3230: work start.
msh >prepare_event_process, step: 1
prepare_event_process, step: 2
prepare_event_process, step: 3
prepare_event_process, step: 4
prepare_event_process, step: 5
I: (bt_hci_core)hci_init_end():3205: work end.
E: (bt_smp)smp_self_test():5695: smp_self_test start
I: (bt_hci_core)bt_dev_show_info():3008: Identity: 02:80:e1:00:00:f5 (public)
I: (bt_hci_core)bt_dev_show_info():3042: HCI: version 5.2 (0x0b) revision 0x1222, manufacturer 0x0030
I: (bt_hci_core)bt_dev_show_info():3044: LMP: version 5.2 (0x0b) subver 0x0015
Bluetooth initialized
Advertising successfully started
Connected
HRS notifications enabled
HRS notifications disabled
Disconnected (reason 0x13)