会不会是你CubeMx版本问题，我目前是v6.11.0。最新的是v6.11.1了。 是可以找到H7S7芯片并创建工程的。 还有，会不会是H7S的CubeMx固件包没加载？不过，联网情况下，没固件包的话，创建 工程时都会提示或通过刷新自动安装。
ST BLE TOOLBOX 只能識別ST提供的在廣播字段中加入了特殊字段的歷程才可以顯示。 参考如下 https://wiki.st.com/stm32mcu/wiki/Connectivity:BLE_smartphone_applications#ST_BLE_Toolbox 按照下面的格式
HAL 库的结构被修改了，好多特殊条件的判断就少了。 所以只能在线调试看看了。 一方面看看状态寄存器是否异常，另一方面看看运行的逻辑是否异常。
找到原因了，应该是供电的原因，一开始为了避免和stlink冲突，我用的都是另外一个usb或者e5v给开发板供电，就会出现这种现象，然后我用stlink那个usb供电，并且将jp1短起来后，使用jlink刷写调试就正常了，现象反正是这样，具体更深入一层的原因我现在也没找到
!(data/attachment/forum/202404/23/182614ld4ah2dhh2kbh5ao.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/300 "image.png")
不明白您说的“Z轴向下为正，X轴向左为正，Y轴朝向自己（正后方）为正"是什么意思？陀螺仪绕Z轴向下？加速度计Z轴向下？ LSM6DSR的轴向是右手定则
是的，我将SPI_EndRxTxTransaction函数中的等待BSY位的阻塞部分注释掉，就不再发生这个情况了。 /* Wait BSY flag during 1 Byte time transfer in case of Full-Duplex and Tx transfer * If Timeout is reached, the transfer is considered as finish. * User have to calculate the timeout value to fit with the time of 1 byte transfer. * This time is directly link with the SPI clock from Master device. */ 看注释，需要修改宏SPI_BSY_FLAG_WORKAROUND_TIMEOUT的值，用来匹配1字节的通信时间。我们的波特率为8MHz左右，那么通信1字节需要1us左右。而HAL库默认是1000us，因此经常在此阻塞，直到超时，或者到下一帧的第一个字节被HAL库接收。 line217 #define SPI_DEFAULT_TIMEOUT 100U line218 #define SPI_BSY_FLAG_WORKAROUND_TIMEOUT 3U /*!< Timeout 1000 µs */
你对I2C模块再初始化之后，确保I2C模块使能并真正退出了busy状态。 然后就可以发送起始位，起始位发送后也会有相应标志，起始标志生成后 就可以继续发送从机地址，发送地址成功的话也有相应标志生成。 一步步检查确认。一般来讲，连线OK，地址给对，通信起来还是挺简便的。 可能的话，尽量使用ST公司提供的库函数，它对各标志的管理很清晰、全面。
微信公众号
手机版
.png)
