STM32WBA52CG 升级到STM32Cube FW_WBA V1.2.0后，调用BleStack_Init后，USART1输出异常

1万 · 2023-12-19 09:13

使用STM32WBA52CG开发蓝牙，板子是NUCLEO-WBA52CG，USART1作为log输出通道。之前使用STM32Cube FW_WBA V1.1.1没什么问题。最近升级了STM32Cube FW_WBA V1.2.0后，发现USART1输出的log乱码了。转换程16进制数是0x30。通过使用printf添加log，发现是在调用了BleStack_Init函数后，USART1固定输出0x30。而这个函数时ST官方提供的蓝牙库里面提供的API，没有源码，很无奈

1万 · 2024-1-12 16:01

查看底层对应代码啊，对比两个版本底层代码改了什么

1万 · 2024-1-12 16:02

API没源码是什么问题，是封装到LIB了？如果不行，还是换回老版本吧。

1万 · 2025-4-8 08:00

看下是不是有UTIL_ADV_TRACE之类的宏启用了？那个trace模块会自动绑定USART1。

1万 · 2025-4-8 08:01

我当时直接关掉了dbg_trace相关配置，然后用自己配置的USART重新打log，问题就没了。

1万 · 2025-4-8 08:01

你可以在MX_USART1_UART_Init函数里加个断点，确认是不是BleStack_Init后被改掉了初始化。

1万 · 2025-4-8 08:02

V1.2.0里面多了一些关于低功耗BLE trace的处理，可能默认用了USART1作为HCI log口。

1万 · 2025-4-8 08:03

我在Release Notes里看到提到debug trace相关更新，可能是这次改动引起的串口冲突。

1万 · 2025-4-8 08:04

我也升级到V1.2.0了，遇到一模一样的问题，感觉是BleStack_Init初始化的时候动了USART的配置。

1万 · 2025-4-8 08:05

看起来像是BleStack库内部重定向了printf或者USART1的句柄，我这边也是输出变成了0x30，挺烦的。

1万 · 2025-4-8 08:06

你有没有试试在BleStack_Init之后重新初始化USART1？我这么干之后log正常了。

1万 · 2025-4-8 08:07

感觉像是某个中间件加了输出钩子，搞不好是调试宏或者低功耗trace那块影响了USART。

1万 · 2025-4-8 08:08

建议你对比下V1.1.1和V1.2.0的app_conf.h或者app_ble.c，可能库版本更新后对串口占用方式改了。

STM32WBA52CG 升级到STM32Cube FW_WBA V1.2.0后，调用BleStack_Init后，USART1输出异常

技术新星奖章

常驻人口

涓涓之细流