STM32中sprintf格式化输出时部分整数始终显示0的问题

1. 初始问题：Relay_mux_1始终显示0的核心原因 #

这是可变参数类型与格式化符不匹配导致的栈读取错位。在STM32常用的GCC编译器中，可变参数传递遵循栈对齐规则：

• uint64_t类型的systick_timestamp会占用8字节栈空间
• 若使用错误的格式化符（比如对应4字节int的%d），sprintf只会从栈中读取4字节作为timestamp的值，剩余4字节会被当成后续参数（Relay_mux_1）的起始位置。而Relay_mux_1是仅占1字节的uint8_t，错位后读取的是栈中无效的0值，所以显示始终为0。

2. 替换Relay_mux_1为固定字符串后，Relay_mux_2显示0的原因 #

本质还是timestamp格式化错误引发的栈错位问题。前面的参数读取错位后，后续所有参数的读取位置都会整体偏移，只是这次受影响的参数从Relay_mux_1变成了Relay_mux_2，因此同样显示0。

3. 使用PRIu64后出现异常的原因 #

大概率是以下两个错误之一：

• 未包含必要头文件：PRIu64宏定义在<inttypes.h>中，若未包含该头文件，编译器会把PRIu64当成普通标识符，直接输出字符串lu，导致格式化符变成%lu（但%lu对应4字节的unsigned long，依然和8字节的uint64_t不匹配）
• 格式化符拼接错误：正确写法需用字符串拼接，示例如下：

  sprintf(log_buf, "Timestamp: %" PRIu64 " Relay_mux_1: %u ...", systick_timestamp, Relay_mux_1, ...);
  

  若写成"Timestamp: %PRIu64"或未用%" PRIu64 "的拼接方式，宏无法正确展开，格式化符失效后会再次引发栈错位，读取到乱码值（比如2292）。

解决建议 #

• 必须包含<inttypes.h>，并用%" PRIu64 "格式化uint64_t类型
• uint8_t类型建议用%u作为格式化符（避免%d可能的符号扩展问题）
• 确保所有参数类型和格式化符严格匹配，比如float类型用%f

内容的提问来源于stack exchange，提问作者Dominykas