将unsigned short赋值给unsigned char位域引发STM32F1复位问题

这是C语言位域实现差异+旧版IAR编译器代码生成bug共同触发的HardFault，最终导致STM32芯片复位，和所谓的“类型不兼容编译错误”无关：

• 你定义的maxM1是基类型为unsigned char的1位无符号位域，合法取值仅为0、1。首次读取EEPROM返回值为0xFFFF（十进制65535），将该值直接赋值给1位位域本身就属于值溢出场景。
• C语言标准仅明确规定了基类型为unsigned int/signed int/_Bool的位域行为，使用unsigned char作为位域基类型属于编译器自定义扩展行为，不同厂商实现逻辑差异极大。
• IAR 6.50版本存在已知代码生成bug：当给unsigned char基类型的位域赋值16位宽度的溢出值时，编译器不会按预期做位宽截断，反而会生成越界的内存访问指令，访问到Cortex-M3内核未映射的地址空间，直接触发总线错误/HardFault，拉低芯片复位。

从C语法规则层面，这段赋值代码完全合法：C标准允许所有算术类型之间进行隐式转换赋值，值溢出属于运行时行为，不属于语法错误。如果未开启最高等级的编译警告，编译器不会给出任何提示。

• 替换位域基类型：不要使用unsigned char作为位域基类型，改用标准明确定义的类型规避编译器bug，参考写法：

  #include <stdbool.h>
  struct s_system {
      bool maxM1 :1;
  };
  

• 赋值前显式做值截断：不要将16位的EEPROM读取结果直接赋值给单个位域，手动提取需要的标志位后再赋值，从根源避免溢出：

  uint16_t eeprom_data = rd_word(MEMORY_ADDRESS);
  // 若标志位对应存储值的第0位，显式做位提取
  sys.maxM1 = (eeprom_data & 0x01U) ? 1 : 0;
  

• 批量映射位域时使用联合体做类型转换：如果需要将16位EEPROM数据整体映射到多成员位域结构体，通过联合体完成转换，同时添加静态断言校验结构体尺寸，避免编译器自动插入填充位导致映射错位：

  #include <stdint.h>
  union sys_conv {
      uint16_t raw_val;
      struct s_system bits;
  };
  _Static_assert(sizeof(union sys_conv) == sizeof(uint16_t), "bitfield size mismatch");
  union sys_conv conv;
  conv.raw_val = rd_word(MEMORY_ADDRESS);
  struct s_system sys = conv.bits;
  

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