在touchGFX生成的MDK工程中调用printf（）存在一个问题，仿真时，前三次点击RUN，程序自动停止，直到第四次才会停止在断点上。且 printf () 不能打印字符。注释掉 printf () 语句，仿真程序点一次运行，程序就正常跑起来。

经过分析，newlib 会通过 semihosting（BKPT 0xAB）依次打开stdin/stdout/stderr，仿真器不处理这条请求，程序就停在 BKPT 上，所以每点一次 Run 只穿过一次打开调用，约 3 次后（第 4 次）才到达断点，此前程序会卡在仿真程序。

针对以上问题，我把 C 库换成 MicroLIB，它本身不依赖 semihosting，再把 printf（） 的输出通过 fputc（） 重定向到串口。

如下：

include <stdio.h>

int fputc(int ch, FILE *f)

{

HAL_UART_Transmit(&huart1, (uint8_t *)&ch, 1, 1000);

return ch;

}

然而经过实际测试，还是同样现象，加printf ()就卡，不加printf ()正常。

此时问题可能出在 HAL 函数本身：HAL_UART_Transmit 内部靠 HAL_GetTick ()（SysTick 中断） 做超时判断，还要轮询 TXE/TC 标志、管理状态机； 在仿真器里，HAL 依赖的是时钟推进 + 标志位时序和仿真器的外设模型配合不上，SysTick 计数不按预期推进，或 USART 模型的 TXE/TC 没按 HAL 等待的条件置位； 结果每个字符都卡在 HAL 的等待循环里，字符根本没写进 TDR，所以既没输出、每个字符还制造一次停顿。

因此将fputc 改成LL库的串口发送，如下：

include "stm32h7xx_ll_usart.h"

int fputc(int ch, FILE *f)

{

volatile uint32_t guard = 0;

while (!LL_USART_IsActiveFlag_TXE(huart3.Instance))

{

if (++guard > 1000000)

break;

}

LL_USART_TransmitData8(huart3.Instance, (uint8_t)ch);

return ch;

}

应用以上LL库的串口重定向，解决了printf ()卡代码的问题。

CubeMX生成的工程暂未发现类似问题。