一、报错本质
HEX 段重叠: 0xFF7A22 (flashseg:auto__str6) 与 0xFF7A22 (flashseg:auto__str0) 重叠
这两条都是链接器（C251 的 LX51）在最后生成 hex 阶段报出的段地址冲突：
flashseg:auto__strN 是编译器为每个 .c 文件里的字符串常量自动生成的常量段（编号 N 按文件顺序分配）。- 两个不同的段被分配到同一个绝对地址 0xFF7A22，因此互相覆盖。
请注意地址 0xFF7A22——它已经超出 16 位（0x10000）范围，是 24 位地址。STC32G12K128 的 Flash 只有 128K，最大合法线性地址是 0x01FFFF。链接器跑到 0xFF7A22，说明它把一个超出芯片真实容量的地址空间当作可用 ROM 来分配了。
二、最可能的原因（按可能性排序）
原因1：ROM 范围设置超出芯片实际容量（最常见）
这是网页版 IDE 最容易出问题的地方。网页 IDE 如果沿用某个模板工程，Code Rom Size 或 ROM 起止地址可能设成 16M（0x000000–0xFFFFFF）范围，链接器便按 16M 来铺段，出现 0xFF7A22 这类地址，而两个段恰好撞在一起。
STC32G12K128 的 Flash 是 128K，ROM 范围必须限制在 0x000000–0x01FFFF。
原因2：代码+常量真的超过了 128K
如果工程确实塞满了 string 常量、大 code 表格，实际占用接近或超过 128K，链接器在越界后地址计算会乱，表现为段重叠。
原因3：网页 IDE 的器件/编译模式选错
网页版 IDE 若器件选了 **STC32G144K246（256K）**或别的更大 Flash 型号，而实际烧的是 12K128（128K），链接器按 256K 布局，也会产生 0xFFxxxx 地址。
原因4：工程里重复加入源文件或重复字符串段
Project 里同一个 .c 被加两次（或同时加了 .c 与 .obj），同一批字符串常量段被链接两次，极易出现 auto__str6 与 auto__str0 同址。
三、排查与解决步骤
- 核对器件型号：确认工程里选的芯片就是 STC32G12K128，不是 144K246 或其他大容量型号。
- 核对 ROM 范围：把 CODE 范围限制在 0x000000–0x01FFFF（128K）。网页 IDE 里通常在“器件/编译选项”或“链接设置”处，若无法直接改，检查是否用的是 STC 官方针对 STC32G12K128 的模板工程。
- 看编译输出 Program Size：
code 行数值若接近 131072（128K），说明真的超容量，需要精简代码/字符串，或换更大 Flash 的型号。
- 检查工程文件列表：确认没有重复添加的 .c / .obj / .lib。
- 清理重建：网页 IDE 一般有“清理/重新编译”按钮，先清全部中间产物再编译，排除旧的 .obj 残留。
四、需要您补充的信息
要精确定位，请提供：
- 网页 IDE 里选择的器件型号；
- 编译输出中的 Program Size 各行（code / const / data / xdata）；
- 工程是否用了 STC 官方 STC32G12K128 模板，还是自建/沿用其他工程；
- 报错是在改代码之后才出现，还是一开始就有。
五、说明
这段报错属于 Keil C251 链接器（LX51）的段分配问题，STC 手册未涉及链接器段布局的说明。上面关于“地址超 128K 说明 ROM 范围设置过大”的判断，是基于报错地址 0xFF7A22 超出 STC32G12K128 的 128K Flash 容量这一事实推出的；芯片 Flash 容量请以 STC32G 系列选型表为准。若您能提供上面四项信息，我可以进一步确认是设置问题还是容量真超。
🔍 搜索 "STC32G12K128 STC网页版IDE HEX段重叠 编译报错"
📌 相关论坛讨论
- STC32G12K128
- IAP_04_移植过程中关于中断向量表的问题
- 自研C语言编译器发布，STC IDE —— 面向 STC32系列及 AI8051U的C语言编译器,11/7更新
⏱️ 查找用时 0.4s | 总回答用时 6.2s
|手机版|深圳国芯人工智能有限公司
( 粤ICP备2022108929号-2 )
已绑定手机
发表于 
已实名认证
发表于