項(xiàng)目的代碼測(cè)試完成之后，準(zhǔn)備收尾時(shí)，出現(xiàn)了問題。清除掉開發(fā)過程中用來調(diào)試的print打印之后，zephyr_polling 的 HCI 突然不能正常工作了，之前測(cè)試可用的 zephyr_polling 中的各個(gè)例程都不再能運(yùn)行。

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

但是顯然不能這樣處理這個(gè)問題，這樣一是治標(biāo)不治本 (只是在這個(gè)環(huán)境下避免了時(shí)序問題的發(fā)生，當(dāng)條件改變，問題還可能出現(xiàn))，二是影響性能。

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

1.是否接收header發(fā)送的太頻繁

先考慮問題是否出在輪詢接收，發(fā)送 header 過于頻繁，導(dǎo)致芯片down。

根據(jù)邏輯時(shí)序圖，很多地方都是發(fā)起接收之后直接讀取芯片的待發(fā)數(shù)據(jù)大小。而此時(shí)芯片并不一定準(zhǔn)備好了做接收，讀到的數(shù)據(jù)大小很大，導(dǎo)致重復(fù)多次地讀取無用 byte。

官方例程里沒有這個(gè)問題是因?yàn)榻邮諘r(shí)中斷調(diào)用的，芯片那邊主動(dòng)要求接收數(shù)據(jù)，一定準(zhǔn)備好發(fā)送了。輪詢的話則應(yīng)該等待芯片做好準(zhǔn)備，拉高irq線再發(fā)送recv_header

處理：

在接收操作發(fā)送 header 前加入 !IsDataAvailable() 校驗(yàn)，確認(rèn)芯片準(zhǔn)備好了再發(fā) header 確定要接收的數(shù)據(jù)量。

加入判斷機(jī)制后大大減少了啟動(dòng)用時(shí)，提高了效率。

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

2.是否是拉高cs_pin后irq_pin響應(yīng)太慢

考慮是否是拉高cs后irq_pin響應(yīng)太慢

觀察時(shí)序圖發(fā)現(xiàn)，MCU 拉高 cs 希望發(fā)送數(shù)據(jù)之后，過了較長一段等待時(shí)間后 irq 才拉高進(jìn)行 header 傳輸。

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

3.是否不能在發(fā)送header之后同時(shí)收發(fā)

在接收處加入校驗(yàn)后的代碼，去掉 print 芯片還是 down 了。觀察其最后的時(shí)序，發(fā)現(xiàn)其發(fā)送了發(fā)送 header 之后，同時(shí)進(jìn)行了收發(fā)，然后 down 了。

沒有delay 發(fā)送接收碰撞 后續(xù)芯片 down 了， spi 通信失敗：

并且，反復(fù)測(cè)試之后，芯片都是在這一次傳輸之后宕機(jī)。這里發(fā)送的命令010cfc032c0101是關(guān)閉芯片自帶 host。同時(shí)傳輸?shù)氖?04ff03:01:000106 廠商事件包，應(yīng)該是一個(gè) 6 字節(jié)的心跳包。

最后的那一個(gè) 06 是因?yàn)?host 要傳輸?shù)拿钍?7 個(gè)字節(jié)，最后有個(gè)隨機(jī)的電平。協(xié)議棧不會(huì)對(duì)芯片的特殊廠商事件包進(jìn)行處理，即使被塞入接收隊(duì)列，最后協(xié)議棧處理的時(shí)候也會(huì)將其丟棄。

考慮是否不能同時(shí)收發(fā)。對(duì)比觀察正常的收發(fā)的時(shí)序。

帶 2 ticks delay 的接收

對(duì)比發(fā)現(xiàn)，正常的工作的傳輸并不會(huì)出現(xiàn)收發(fā)同時(shí)的情況。

拋開這個(gè)宕機(jī)問題不談，在發(fā)送的事務(wù)流程中，對(duì)于傳輸數(shù)據(jù)過程中芯片發(fā)過來的數(shù)據(jù)是直接丟棄的，而這將導(dǎo)致丟包。雖然這里丟失的是廠商事件包，本來就不會(huì)對(duì)其處理，但是處于普適性應(yīng)該將其糾正。

解決同時(shí)收發(fā)的問題

觀察時(shí)序圖發(fā)現(xiàn)，發(fā)送 header 之后不進(jìn)行數(shù)據(jù)傳輸時(shí)被芯片允許的。嘗試在實(shí)際發(fā)送之前檢查 send_header 響應(yīng)中接收緩沖區(qū)數(shù)據(jù)量，如果不為 0，結(jié)束當(dāng)此發(fā)送流程，先做一次完整接收，并將接收到的數(shù)據(jù)塞到接收隊(duì)列里，再重新發(fā)送 send_header (使用while循環(huán)，直到待接收數(shù)據(jù)為0)，繼續(xù)當(dāng)前數(shù)據(jù)的發(fā)送。

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

/* 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);
}

測(cè)試發(fā)現(xiàn)并不行，這時(shí)想起我沒拉高 CS 結(jié)束這一次發(fā)送傳輸事務(wù)就直接啟動(dòng)了一次接收，肯定會(huì)出錯(cuò)。加入這一句：rt_pin_write(HCI_TL_SPI_CS_PIN, PIN_HIGH);。

但加入后仍然不能正常使用。發(fā)送超時(shí)了，也就是在發(fā)起接收的時(shí)候， 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)

查看時(shí)序圖：

發(fā)現(xiàn)后續(xù)irq_pin直到超時(shí)了都沒動(dòng)一下，懷疑是前一次的發(fā)送流程沒有被芯片認(rèn)定結(jié)束。

經(jīng)過一系列嘗試和測(cè)試之后，發(fā)現(xiàn)要想結(jié)束當(dāng)次發(fā)送流程，需要將 cs 拉高一定的時(shí)間，才能讓 chipset 覺得這次發(fā)送完了：

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;
}

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

修改后芯片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)