RT-Thread-RTT平台 zephyr_polling软件包 SPI Bluenrg2芯片宕机问题与修复RT-Thread问答社区

RTT平台 zephyr_polling软件包 SPI Bluenrg2芯片宕机问题与修复

发布于 2023-09-23 21:04:31 浏览：87 订阅该版

[tocm]

# RTT zephyr_polling SPI Bluenrg2芯片宕机问题与修复

>“开源之夏”“蓝牙HOST协议栈zephyr_polling完善” 项目个人记录
菜鸡参与项目的个人记录
项目软件包地址：https://github.com/bobwenstudy/RTT_PACKAGE_zephyr_polling

项目的代码测试完成之后，准备收尾时，出现了问题。清除掉开发过程中用来调试的print打印之后，zephyr_polling 的 HCI 突然不能正常工作了，之前测试可用的 zephyr_polling 中的各个例程都不再能运行。
这个时候是去掉了 print 打印的，不能从日志找问题。经过一个一个尝试之后定位到了 SPI 接收操作完成之后的一个 print。将其去掉之后，芯片运行会宕机，但若是替换为一个 2 ticks (即2ms)的时延，例程都能正常运行。但是显然不能这样处理这个问题，这样一是治标不治本 (只是在这个环境下避免了时序问题的发生，当条件改变，问题还可能出现)，二是影响性能。

于是使用这个(不太好用的)逻辑分析仪开始寻找问题。

## 1.是否接收header发送的太频繁

先考虑问题是否出在轮询接收，发送 header 过于频繁，导致芯片down。

根据逻辑时序图，很多地方都是发起接收之后直接读取芯片的待发数据大小。而此时芯片并不一定准备好了做接收，读到的数据大小很大，导致重复多次地读取无用 byte。

![2023-09-23-16-42-54.png](https://oss-club.rt-thread.org/uploads/20230923/488d206cde1f571b0f3127a6f9acb4ce.png.webp)

官方例程里没有这个问题是因为接收时中断调用的，芯片那边主动要求接收数据，一定准备好发送了。轮询的话则应该等待芯片做好准备，拉高irq线再发送recv_header

**处理**：

在接收操作发送 header 前加入 !IsDataAvailable() 校验，确认芯片准备好了再发 header 确定要接收的数据量。

加入判断机制后大大减少了启动用时，提高了效率。

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

## 2.是否是拉高cs_pin后irq_pin响应太慢

考虑是否是拉高cs后irq_pin响应太慢

观察时序图发现，MCU 拉高 cs 希望发送数据之后，过了较长一段等待时间后 irq 才拉高进行 header 传输。

![2023-09-23-17-09-01.png](https://oss-club.rt-thread.org/uploads/20230923/b91f5a530542c8d58f2173d366bad32e.png.webp)

测试这种情况：cs 拉高再拉低，等待较长一段时间才 irq 拉高，此时传输数据，芯片并没有 down：
![2023-09-23-17-10-10.png](https://oss-club.rt-thread.org/uploads/20230923/2da680c22d048d1da3322fa02a81acb8.png.webp)

## 3.是否不能在发送header之后同时收发

在接收处加入校验后的代码，去掉 print 芯片还是 down 了。观察其最后的时序，发现其发送了发送 header 之后，同时进行了收发，然后 down 了。

没有delay 发送接收碰撞  后续芯片 down 了， spi 通信失败：

![2023-09-23-16-45-49.png](https://oss-club.rt-thread.org/uploads/20230923/be0b00c9387f1466174293d804dc1ea9.png.webp)
![2023-09-23-16-46-00.png](https://oss-club.rt-thread.org/uploads/20230923/b91f5a530542c8d58f2173d366bad32e.png.webp)

并且，反复测试之后，芯片都是在这一次传输之后宕机。这里发送的命令`01:0c:fc:03:2c:01:01`是关闭芯片自带 host。同时传输的是 `04:ff:03:01:00:01:06` 厂商事件包，应该是一个 6 字节的心跳包。最后的那一个 `06` 是因为 host 要传输的命令是 7 个字节，最后有个随机的电平。协议栈不会对芯片的特殊厂商事件包进行处理，即使被塞入接收队列，最后协议栈处理的时候也会将其丢弃。

**考虑是否不能同时收发**。对比观察正常的收发的时序。

带 2 ticks delay 的接收
![2023-09-23-16-57-38.png](https://oss-club.rt-thread.org/uploads/20230923/9eec2f5206f160932b9c7a95ad889393.png.webp)

带 2 ticks delay 的接收，无待传数据
![2023-09-23-16-57-52.png](https://oss-club.rt-thread.org/uploads/20230923/b72bebe815f4b15369bb750610beb569.png.webp)
![2023-09-23-16-58-10.png](https://oss-club.rt-thread.org/uploads/20230923/4070abb02c3206577c691fa18e39a2b3.png.webp)

对比发现，正常的工作的传输并不会出现收发同时的情况。
抛开这个宕机问题不谈，在发送的事务流程中，对于传输数据过程中芯片发过来的数据是直接丢弃的，而这将导致丢包。虽然这里丢失的是厂商事件包，本来就不会对其处理，但是处于普适性应该将其纠正。

## 解决同时收发的问题

观察时序图发现，发送 header 之后不进行数据传输时被芯片允许的。尝试在实际发送之前检查 send_header 响应中接收缓冲区数据量，如果不为 0，结束当此发送流程，先做一次完整接收，并将接收到的数据塞到接收队列里，再重新发送 send_header (使用while循环，直到待接收数据为0)，继续当前数据的发送。

直接在 send_header 传输完成之后加入判断，进行一次接收：

```C
    /* 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 一直没有拉高

查看时序图：
![2023-09-23-20-37-32.png](https://oss-club.rt-thread.org/uploads/20230923/6001bb0ec63388d9da72540fe15d8246.png.webp)

发现后续irq_pin直到超时了都没动一下，怀疑是前一次的发送流程没有被芯片认定结束。

经过一系列尝试和测试之后，发现要想结束当次发送流程，需要将 cs 拉高一定的时间，才能让 chipset 觉得这次发送完了：

```c
    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掉的问题得到解决：

```shel
 \ | /
- 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)
```