1. 先说结论这不是单一原因而是一整条故障链STM32WB55出现“cannot be read, erased, programmed”这类报错十有八九不是芯片物理损坏而是调试接口状态、Option Bytes配置或双核唤醒机制出了问题。我前前后后经手过十几块WB55的开发板和自绘板每次遇到这种问题第一反应都不是怀疑芯片“假砖”而是先走一套固定的排查流程接线、供电、复位、连接方式、读保护等级、双核调试会话最后才是芯片本身。这篇文章会把完整排查思路写出来。适合两类人看一类是用STM32WB55做低功耗蓝牙或Zigbee产品开发烧录时突然连不上芯片的工程师另一类是刚拿到官方评估板第一次接ST-Link就报错的入门玩家。无论你是用STM32CubeProgrammer还是Keil/IAR底层逻辑都一样只是报错文本略有差异。先给你一个定心丸STM32WB55这颗芯片的设计相当皮实真正因为内部Flash物理损坏导致无法编程的情况极少。绝大多数“cannot read/erase/program”都集中在连接状态、保护位、低功耗模式或双核仲裁这几个环节。下面我按实际排查顺序展开你能直接照着操作。2. 排查步骤一硬件连接与供电别急着怪芯片2.1 复位电容、调试引脚、供电波纹我先说一个最容易忽略的坑STM32WB55沿用SWD调试接口但它的NRST引脚对复位电路比较敏感。很多自绘板为了省事直接在NRST上接一个0.1uF电容这本身没问题问题出在电容取值过大或者ST-Link和目标板之间还存在另一套复位电路。一旦复位脉冲被拉低时间过长连接阶段就反复失败报错表现就是“cannot read”或“connection error”。另一个高频故障点是供电。WB55内置射频前端瞬态电流比普通MCU大启动瞬间如果电源纹波偏大内部LDO无法稳定建立内核可能处于一种“半睡半醒”的状态。这种情况下调试口尽管能检测到设备但读取IDCODE失败或者读出来一个全是0xFF/0x00的IDST-Link直接放弃连接。我遇到过一次板子用AMS1117从5V转3.3V输出端只放了10uF电容结果在射频发射瞬间电压跌落超过200mV每次连接成功率不到一半。排查时我一般这样操作先用USB供电或外部稳压电源给目标板独立供电ST-Link和板子之间只连SWDIO、SWCLK、GND不连3.3V排除调试器供电能力不足的干扰。然后示波器看NRST复位释放后的上升沿正常应该是干净的单次上升沿如果看到多次毛刺或缓慢爬升先处理复位电路。2.2 换线、换ST-Link、手动复位连接线是另一个容易被忽略的变量。SWD虽然只有四根线但工作在几MHz速率下杜邦线过长或者接触不良会导致时钟边沿变形。我踩过最狠的一次用了30厘米的杜邦线连接CubeProgrammer能识别到芯片但一执行read就报“Error: cannot read memory”换成10厘米以内的杜邦线后问题消失。SWDIO和SWCLK最好等长且不要和射频天线部分靠太近否则蓝牙发射时调试口直接断连。如果你用的是山寨ST-Link还要留意固件版本。老版本ST-Link固件对WB55双核调试支持不完善读ID时能通过进入调试模式后却无法控制CPU。建议先升级到ST-Link On-Board固件最新版或者在STM32CubeProgrammer里刷新固件。实在不行换一个官方STLINK-V3SET或J-Link很多奇葩问题直接消失。还有一个“土办法”很有效在CubeProgrammer里把连接速度从默认的4MHz降到1MHz或更低。WB55的SWD引脚与射频相关功能存在复用某些情况下高速连接不稳定降速虽然慢一点但能显著提高连接成功率。我现在的习惯是评估板用4MHz自绘板和长线场景一律降到1.8MHz或1MHz。3. 排查步骤二调试接口被“锁死”的几种可能3.1 RDP读保护等级如果硬件连接没问题供电也稳定但STM32CubeProgrammer仍然提示无法读取Flash或执行擦除那就要考虑RDP读保护等级。STM32WB55的Option Bytes里有一个RDP位分为三个等级Level 0无保护全功能开放正常读写擦除。Level 1禁止通过调试接口读取Flash内容但仍允许擦除和重新编程前提是连接时CPU处于复位状态或调试端口已释放。Level 2最高保护调试接口永久锁定芯片上几乎无法通过SWD恢复只能通过系统Bootloader或特定手段处理且某些情况下是不可逆的。很多量产板出厂时会被设置成Level 1防止固件被读取。如果你拿到的是别人的板子、二手核心板或测试遗留板连接后看到“Read protection is enabled”或者“Error: Cannot read memory”就非常正常。这种情况下并不是芯片坏了而是需要先做一次“全片擦除”或“解除读保护”。这里有个关键点从Level 1回到Level 0常规操作是勾选CubeProgrammer里的“Remove read protection”选项执行后芯片会自动执行一次全片擦除。这意味着板上固件会消失同时也解释了一个现象——为什么很多人“刚连上就报错想读Firmware却全读成0xFF”。不是你操作有问题而是保护机制不允许你在不擦除的前提下读取任何数据。3.2 TrustZone与Option BytesSTM32WB55在较新的固件包里启用了TrustZone安全扩展后调试连接机制会有明显变化。如果你启用了TrustZone那么芯片会被划分成安全区和非安全区调试端口需要先获取安全区访问权限否则只能看到非安全区的部分内容甚至连IDCODE读取都受限。这种情况下的报错往往是“Cannot access target”或“RDP level not supported”。我早期调试一个带TrustZone的示例工程时反复出现“cannot read”的问题后来发现是因为TZEN位被置1而CubeProgrammer的默认连接配置没有勾选“Enable TrustZone”相关的访问模式。遇到这类问题可以先连接后查看Option Bytes页面确认TZEN、RDP、BOR等关键位。如果TZEN处于使能状态而你暂时不用TrustZone可以尝试把TZEN清0。但要注意TZEN位只能在特定条件下修改部分芯片还需要先执行整片擦除才能改变。若你的产品确实要用TrustZone那就要用支持TrustZone的调试工具和连接参数不是拉一根SWD线就能解决的。3.3 双核架构的影响STM32WB55不是单核MCU它内部有Cortex-M4应用核和Cortex-M0网络协处理核。M0核负责蓝牙协议栈/Zigbee协议栈M4核负责用户应用。问题在于两个核共享内部Flash和部分外设调试端口也由统一调试子系统管理。如果你之前用M0核做过调试或者跑过协议栈固件而M0核当前处于低功耗睡眠或锁定状态M4核的调试会话可能无法正常访问Flash。典型现象是CubeProgrammer识别到设备但一执行读取或擦除命令就卡住或立即报错。解决办法是使用STM32CubeProgrammer的“Dual Core”调试模式或者连接时选择“System Bootloader”而不是“Hot Plug”。使用System Bootloader模式时芯片会重启并进入内嵌Bootloader此时两个核都被复位调试端口不再受当前运行固件干扰执行全片擦除和重新编程的成功率会高很多。这也是救砖时最推荐的连接方式。4. 实战操作怎么救回一个“假砖”的WB554.1 用STM32CubeProgrammer强制连接先说明我以下步骤均以STM32CubeProgrammer 1.15及以上版本为例。新版本对WB55支持更好尤其是对双核和TrustZone的处理更成熟。如果你还在用老版本建议先升级不然很多选项根本看不到。打开软件后右上角选择ST-LINK接口选SWD频率降到低档然后不要直接点Connect。在“Mode”里选择“Under reset”或“Hot Plug”。“Under reset”要求在芯片复位期间建立连接适合当前固件把调试口配置成普通IO、或程序跑飞导致调试口失效的场景。标准救砖流程我先建议“Under reset”如果失败再切“Hot Plug”。点击Connect后观察日志区域。如果提示“Device ID 0x495”之类的ID说明连接成功。此时不要急着点Read先进入Option Bytes页面看一眼RDP等级。如果是Level 1直接下拉选择Level 0点击Apply。软件会弹窗提醒将执行全片擦除确认后等待完成。注意解除读保护的过程需要断开已有调试会话重新连接芯片会先擦除全部Flash再恢复RDP为Level 0。这个过程不能断电否则Option Bytes可能写入不完整导致进入更麻烦的状态。4.2 解除读保护的正确姿势解除读保护在CubeProgrammer里非常直观但我遇到过几个细节问题第一如果你连接时选了“Hot Plug”而芯片CPU正运行着低功耗代码解除读保护的操作可能失败。因为写Option Bytes需要CPU配合CPU睡死的话操作无法完成。这时一定要用“Under reset”模式重连。第二如果芯片的RDP已经是Level 2CubeProgrammer会直接拒绝所有调试操作此时普通SWD是不可解的。唯一常规恢复路径是使用芯片内嵌的Bootloader通过USART或USB接口执行System Bootloader擦除。STM32WB55的Bootloader默认支持USART1和USB需要把BOOT0引脚拉高再复位然后用CubeProgrammer选择UART或USB接口连接执行擦除。第三解除保护后芯片的Option Bytes里其他配置也会被重置比如看门狗选择、BOR级别、Flash双Bank模式。回读一遍Option Bytes确认和你预期一致。我见过有同事解保护后忘记重新配置BOR导致低温环境下芯片复位异常排查了很久。4.3 擦除全片与恢复默认Option Bytes连接成功后点击“Full chip erase”按钮会执行整片擦除。这对WB55来说很安全它会同时擦除M4核和M0核的Flash区包括用户选项区之外的主存储区。擦除期间如果看到报错“Cannot erase memory”大概率是RDP保护等级还没降下来。擦除完成后再做一次全片Verify。如果地址0x08000000处全部为0xFF说明擦除干净了。此时先不急着下载程序建议先执行“Option Bytes”页面里的“Restore Default”或手动把RDP设为Level 0TZEN设为0BOR等级设为合适值。这样做的目的是把芯片恢复成出厂状态排除遗留配置干扰后续开发。恢复默认Option Bytes后断电重新上电再次用SWD连接此时应该能顺畅读取到空片状态。此时烧录一个最简单的LED闪烁工程验证MCU是否完全恢复。如果一切正常说明芯片没问题之前只是保护位和调试配置在作祟。4.4 编写脚本化处理如果你手头有多块板子需要恢复每次都点GUI未免太慢。STM32CubeProgrammer提供了命令行工具STM32_Programmer_CLI可以写脚本来批量处理。以下是我在实际生产测试中常用的命令STM32_Programmer_CLI -c portSWD modeUR resetHWrst -ob RDP0 STM32_Programmer_CLI -c portSWD modeUR resetHWrst -e all -v STM32_Programmer_CLI -c portSWD modeUR resetHWrst -w firmware.hex -v第一条命令用于解除读保护第二条执行全片擦除和校验第三条烧录固件并校验。如果你需要取消TrustZone可以追加参数STM32_Programmer_CLI -c portSWD modeUR resetHWrst -ob TZEN0使用脚本化处理时有一点要提醒如果你的连接线质量一般擦除和烧录过程中意外中断芯片可能留在半擦除状态。脚本层面最好加一个失败重试机制比如总次数小于3次每次失败后重新连接。量产阶段我更推荐用独立的烧录夹具和短距离连接线保证稳定。5. 常见错误与提示速查表5.1 “Cannot read”等错误含义我整理了一份速查表覆盖我实际见过的错误文本和对应处理方向。注意STM32CubeProgrammer和第三方IDE的报错措辞可能不同但本质问题基本可以对应报错关键词可能原因优先处理Cannot read memoryRDP保护、连接不稳定、CPU低功耗检查RDP等级切换Under reset降低SWD速率Cannot erase memoryRDP Level 1/Level 2、Flash写保护先解除读保护再全片擦除Cannot connect / Connection error接线错误、供电异常、ST-Link固件旧换线、验证供电、升级ST-Link固件Device ID mismatch / 0x000000SWD信号问题、目标板未上电、复位电路异常检查NRST、SWDIO/SWCLK手动拉低复位再连RDP Level 2芯片最高级保护仅能通过Bootloader或更换芯片Cannot access targetTrustZone使能、调试端口被禁用查看TZEN位尝试System Bootloader模式Error: connection error 0xE2E0ST-Link非法命令或目标未响应降低频率用UR模式重试这张表并不是官方文档的精确定义而是我根据实际排障经验做的映射。拿“Cannot read memory”来说可能有五六种细微原因但表格里的优先级是我验证过概率最高的顺序。我在处理问题时习惯先排除硬件连接再排除保护位最后才怀疑芯片。因为怀疑芯片是成本最高也最不容易改变主意的方向往往浪费一两天后才发现只是Option Bytes没配置对。5.2 排查优先级如果你现在手头正好有一块连不上的WB55建议按这个顺序操作每一步都记录下现象避免重复操作确认板子供电正常测量3.3V稳定且在复位和射频发射时没有明显跌落。检查SWDIO、SWCLK、GND是否连接可靠是否使用过长导线。用STM32CubeProgrammer选择SWD、频率1MHz、Under reset模式尝试连接。如果连接成功先查看Option Bytes里的RDP、TZEN、BOR、Flash保护位。如果RDP为Level 1执行Remove protection允许全片擦除。如果连接失败尝试System Bootloader模式通过BOOT0引脚进入Bootloader再用UART/USB连接。擦除全片恢复默认配置重新验证。如果以上全部失败再考虑硬件层面的问题比如OXIDE损坏、晶振异常、焊盘短路。这套顺序我写进了团队的新人培训文档里目的就是防止新手一上来就“大力出奇迹”直接在GUI里乱点导致Option Bytes越弄越糟。有条理地记录每一步结果比盲目尝试几十种连法要快得多。6. 我的几点实操心得6.1 关于下载调试STM32WB55的调试体验比STM32F1系列要“矫情”不少。F1时代我随便拿四根杜邦线就能连WB55则对布线、复位和供电环境更敏感。尤其是自绘PCB建议SWDIO和SWCLK上各加一个33欧姆串联电阻靠近MCU放置能有效抑制振铃。如果产品空间允许再留一个测试点接到NRST救砖时会非常省事。另外WB55的M0核和M4核共享Flash但并非所有调试器都能同时良好支持。IAR较新版本对双核调试支持不错但如果你只是烧录用户应用建议在CubeProgrammer里选择“Erase sectors”而不是“Erase full chip”这样只擦除M4核应用所在扇区保留M0核的协议栈固件。不然你全片擦除后蓝牙协议栈固件也消失了重新下载BLE固件是另一套繁琐流程。6.2 关于低功耗这是我踩得最深的一个坑。WB55常用于低功耗场景工程师喜欢在代码里立刻进入Sleep模式或Stop模式。如果你调试时连接那一刻CPU正睡死SWD会经常无法建立稳定连接。不是说SWD不能唤醒CPU而是唤醒过程和调试端口仲裁的时序在特定条件下会冲突。后来我的习惯是开发阶段先把低功耗相关代码用宏关掉保证CPU一直活跃调试完再打开。如果产品需要验证真实低功耗行为我会在代码里加一个“调试模式”上电后等待10秒再进入低功耗给调试器充足时间连接。这样既不牺牲产品逻辑又保住了可调试性。遇到“插上ST-Link就正常拔掉就各种奇怪复位”的板子也优先检查是不是低功耗进入时序把调试引脚状态改变了。6.3 关于量产量产阶段遇到“cannot read, erased, programmed”最头疼因为板子数量多人工排查不现实。我的方案是在产线治具上固定使用STM32CubeProgrammer命令行脚本烧录前先执行一次Option Bytes检查确认RDP等级和TZEN状态。如果检测到非预期状态自动执行全片擦除和Option Bytes恢复再继续烧录。脚本里还要加入日志输出把每块板的序列号、MAC地址、烧录结果写进文件。这样一旦出现批量问题可以回头定位是连接异常、读保护状态异常还是Flash编程失败。我遇到过一批板子在产线上大概有3%连不上排查后确认是某批焊接物料导致SWCLK引脚虚焊而不是固件问题。如果没有日志和批量脚本这类问题会非常隐蔽。最后分享一个救砖小技巧如果你手上的WB55已经被折腾到“Under reset”也连不上的地步可以先尝试把ST-Link的SWD频率降到最低部分工具可以到几百kHz连接时按住板子复位键不放点击Connect后再松开。原理是让调试器在芯片复位释放的瞬间抢占调试端口这招对“固件启动后立刻改引脚功能”的板子特别有效。我个人在实际排查中还有一个小癖好每次连接前都先量一下SWDIO引脚对地电阻正常应该呈二极管特性大约0.5V压降。如果测出直接短路或高阻就不用浪费时间去查软件了先解决焊接问题。这个方法简单但很管用尤其在量产现场没有示波器的时候。毕竟STM32WB55这颗芯片本身并不容易坏绝大多数时候都是外围环境在制造问题找到它、解决它芯片自然就活了。 
长河君 · 2026/8/30 4:41:56 · 阅读 1.2k STM32WB55无法烧录？一文讲透调试接口与读保护排查全流程
1. 先说结论这不是单一原因而是一整条故障链STM32WB55出现“cannot be read, erased, programmed”这类报错十有八九不是芯片物理损坏而是调试接口状态、Option Bytes配置或双核唤醒机制出了问题。我前前后后经手过十几块WB55的开发板和自绘板每次遇到这种问题第一反应都不是怀疑芯片“假砖”而是先走一套固定的排查流程接线、供电、复位、连接方式、读保护等级、双核调试会话最后才是芯片本身。这篇文章会把完整排查思路写出来。适合两类人看一类是用STM32WB55做低功耗蓝牙或Zigbee产品开发烧录时突然连不上芯片的工程师另一类是刚拿到官方评估板第一次接ST-Link就报错的入门玩家。无论你是用STM32CubeProgrammer还是Keil/IAR底层逻辑都一样只是报错文本略有差异。先给你一个定心丸STM32WB55这颗芯片的设计相当皮实真正因为内部Flash物理损坏导致无法编程的情况极少。绝大多数“cannot read/erase/program”都集中在连接状态、保护位、低功耗模式或双核仲裁这几个环节。下面我按实际排查顺序展开你能直接照着操作。2. 排查步骤一硬件连接与供电别急着怪芯片2.1 复位电容、调试引脚、供电波纹我先说一个最容易忽略的坑STM32WB55沿用SWD调试接口但它的NRST引脚对复位电路比较敏感。很多自绘板为了省事直接在NRST上接一个0.1uF电容这本身没问题问题出在电容取值过大或者ST-Link和目标板之间还存在另一套复位电路。一旦复位脉冲被拉低时间过长连接阶段就反复失败报错表现就是“cannot read”或“connection error”。另一个高频故障点是供电。WB55内置射频前端瞬态电流比普通MCU大启动瞬间如果电源纹波偏大内部LDO无法稳定建立内核可能处于一种“半睡半醒”的状态。这种情况下调试口尽管能检测到设备但读取IDCODE失败或者读出来一个全是0xFF/0x00的IDST-Link直接放弃连接。我遇到过一次板子用AMS1117从5V转3.3V输出端只放了10uF电容结果在射频发射瞬间电压跌落超过200mV每次连接成功率不到一半。排查时我一般这样操作先用USB供电或外部稳压电源给目标板独立供电ST-Link和板子之间只连SWDIO、SWCLK、GND不连3.3V排除调试器供电能力不足的干扰。然后示波器看NRST复位释放后的上升沿正常应该是干净的单次上升沿如果看到多次毛刺或缓慢爬升先处理复位电路。2.2 换线、换ST-Link、手动复位连接线是另一个容易被忽略的变量。SWD虽然只有四根线但工作在几MHz速率下杜邦线过长或者接触不良会导致时钟边沿变形。我踩过最狠的一次用了30厘米的杜邦线连接CubeProgrammer能识别到芯片但一执行read就报“Error: cannot read memory”换成10厘米以内的杜邦线后问题消失。SWDIO和SWCLK最好等长且不要和射频天线部分靠太近否则蓝牙发射时调试口直接断连。如果你用的是山寨ST-Link还要留意固件版本。老版本ST-Link固件对WB55双核调试支持不完善读ID时能通过进入调试模式后却无法控制CPU。建议先升级到ST-Link On-Board固件最新版或者在STM32CubeProgrammer里刷新固件。实在不行换一个官方STLINK-V3SET或J-Link很多奇葩问题直接消失。还有一个“土办法”很有效在CubeProgrammer里把连接速度从默认的4MHz降到1MHz或更低。WB55的SWD引脚与射频相关功能存在复用某些情况下高速连接不稳定降速虽然慢一点但能显著提高连接成功率。我现在的习惯是评估板用4MHz自绘板和长线场景一律降到1.8MHz或1MHz。3. 排查步骤二调试接口被“锁死”的几种可能3.1 RDP读保护等级如果硬件连接没问题供电也稳定但STM32CubeProgrammer仍然提示无法读取Flash或执行擦除那就要考虑RDP读保护等级。STM32WB55的Option Bytes里有一个RDP位分为三个等级Level 0无保护全功能开放正常读写擦除。Level 1禁止通过调试接口读取Flash内容但仍允许擦除和重新编程前提是连接时CPU处于复位状态或调试端口已释放。Level 2最高保护调试接口永久锁定芯片上几乎无法通过SWD恢复只能通过系统Bootloader或特定手段处理且某些情况下是不可逆的。很多量产板出厂时会被设置成Level 1防止固件被读取。如果你拿到的是别人的板子、二手核心板或测试遗留板连接后看到“Read protection is enabled”或者“Error: Cannot read memory”就非常正常。这种情况下并不是芯片坏了而是需要先做一次“全片擦除”或“解除读保护”。这里有个关键点从Level 1回到Level 0常规操作是勾选CubeProgrammer里的“Remove read protection”选项执行后芯片会自动执行一次全片擦除。这意味着板上固件会消失同时也解释了一个现象——为什么很多人“刚连上就报错想读Firmware却全读成0xFF”。不是你操作有问题而是保护机制不允许你在不擦除的前提下读取任何数据。3.2 TrustZone与Option BytesSTM32WB55在较新的固件包里启用了TrustZone安全扩展后调试连接机制会有明显变化。如果你启用了TrustZone那么芯片会被划分成安全区和非安全区调试端口需要先获取安全区访问权限否则只能看到非安全区的部分内容甚至连IDCODE读取都受限。这种情况下的报错往往是“Cannot access target”或“RDP level not supported”。我早期调试一个带TrustZone的示例工程时反复出现“cannot read”的问题后来发现是因为TZEN位被置1而CubeProgrammer的默认连接配置没有勾选“Enable TrustZone”相关的访问模式。遇到这类问题可以先连接后查看Option Bytes页面确认TZEN、RDP、BOR等关键位。如果TZEN处于使能状态而你暂时不用TrustZone可以尝试把TZEN清0。但要注意TZEN位只能在特定条件下修改部分芯片还需要先执行整片擦除才能改变。若你的产品确实要用TrustZone那就要用支持TrustZone的调试工具和连接参数不是拉一根SWD线就能解决的。3.3 双核架构的影响STM32WB55不是单核MCU它内部有Cortex-M4应用核和Cortex-M0网络协处理核。M0核负责蓝牙协议栈/Zigbee协议栈M4核负责用户应用。问题在于两个核共享内部Flash和部分外设调试端口也由统一调试子系统管理。如果你之前用M0核做过调试或者跑过协议栈固件而M0核当前处于低功耗睡眠或锁定状态M4核的调试会话可能无法正常访问Flash。典型现象是CubeProgrammer识别到设备但一执行读取或擦除命令就卡住或立即报错。解决办法是使用STM32CubeProgrammer的“Dual Core”调试模式或者连接时选择“System Bootloader”而不是“Hot Plug”。使用System Bootloader模式时芯片会重启并进入内嵌Bootloader此时两个核都被复位调试端口不再受当前运行固件干扰执行全片擦除和重新编程的成功率会高很多。这也是救砖时最推荐的连接方式。4. 实战操作怎么救回一个“假砖”的WB554.1 用STM32CubeProgrammer强制连接先说明我以下步骤均以STM32CubeProgrammer 1.15及以上版本为例。新版本对WB55支持更好尤其是对双核和TrustZone的处理更成熟。如果你还在用老版本建议先升级不然很多选项根本看不到。打开软件后右上角选择ST-LINK接口选SWD频率降到低档然后不要直接点Connect。在“Mode”里选择“Under reset”或“Hot Plug”。“Under reset”要求在芯片复位期间建立连接适合当前固件把调试口配置成普通IO、或程序跑飞导致调试口失效的场景。标准救砖流程我先建议“Under reset”如果失败再切“Hot Plug”。点击Connect后观察日志区域。如果提示“Device ID 0x495”之类的ID说明连接成功。此时不要急着点Read先进入Option Bytes页面看一眼RDP等级。如果是Level 1直接下拉选择Level 0点击Apply。软件会弹窗提醒将执行全片擦除确认后等待完成。注意解除读保护的过程需要断开已有调试会话重新连接芯片会先擦除全部Flash再恢复RDP为Level 0。这个过程不能断电否则Option Bytes可能写入不完整导致进入更麻烦的状态。4.2 解除读保护的正确姿势解除读保护在CubeProgrammer里非常直观但我遇到过几个细节问题第一如果你连接时选了“Hot Plug”而芯片CPU正运行着低功耗代码解除读保护的操作可能失败。因为写Option Bytes需要CPU配合CPU睡死的话操作无法完成。这时一定要用“Under reset”模式重连。第二如果芯片的RDP已经是Level 2CubeProgrammer会直接拒绝所有调试操作此时普通SWD是不可解的。唯一常规恢复路径是使用芯片内嵌的Bootloader通过USART或USB接口执行System Bootloader擦除。STM32WB55的Bootloader默认支持USART1和USB需要把BOOT0引脚拉高再复位然后用CubeProgrammer选择UART或USB接口连接执行擦除。第三解除保护后芯片的Option Bytes里其他配置也会被重置比如看门狗选择、BOR级别、Flash双Bank模式。回读一遍Option Bytes确认和你预期一致。我见过有同事解保护后忘记重新配置BOR导致低温环境下芯片复位异常排查了很久。4.3 擦除全片与恢复默认Option Bytes连接成功后点击“Full chip erase”按钮会执行整片擦除。这对WB55来说很安全它会同时擦除M4核和M0核的Flash区包括用户选项区之外的主存储区。擦除期间如果看到报错“Cannot erase memory”大概率是RDP保护等级还没降下来。擦除完成后再做一次全片Verify。如果地址0x08000000处全部为0xFF说明擦除干净了。此时先不急着下载程序建议先执行“Option Bytes”页面里的“Restore Default”或手动把RDP设为Level 0TZEN设为0BOR等级设为合适值。这样做的目的是把芯片恢复成出厂状态排除遗留配置干扰后续开发。恢复默认Option Bytes后断电重新上电再次用SWD连接此时应该能顺畅读取到空片状态。此时烧录一个最简单的LED闪烁工程验证MCU是否完全恢复。如果一切正常说明芯片没问题之前只是保护位和调试配置在作祟。4.4 编写脚本化处理如果你手头有多块板子需要恢复每次都点GUI未免太慢。STM32CubeProgrammer提供了命令行工具STM32_Programmer_CLI可以写脚本来批量处理。以下是我在实际生产测试中常用的命令STM32_Programmer_CLI -c portSWD modeUR resetHWrst -ob RDP0 STM32_Programmer_CLI -c portSWD modeUR resetHWrst -e all -v STM32_Programmer_CLI -c portSWD modeUR resetHWrst -w firmware.hex -v第一条命令用于解除读保护第二条执行全片擦除和校验第三条烧录固件并校验。如果你需要取消TrustZone可以追加参数STM32_Programmer_CLI -c portSWD modeUR resetHWrst -ob TZEN0使用脚本化处理时有一点要提醒如果你的连接线质量一般擦除和烧录过程中意外中断芯片可能留在半擦除状态。脚本层面最好加一个失败重试机制比如总次数小于3次每次失败后重新连接。量产阶段我更推荐用独立的烧录夹具和短距离连接线保证稳定。5. 常见错误与提示速查表5.1 “Cannot read”等错误含义我整理了一份速查表覆盖我实际见过的错误文本和对应处理方向。注意STM32CubeProgrammer和第三方IDE的报错措辞可能不同但本质问题基本可以对应报错关键词可能原因优先处理Cannot read memoryRDP保护、连接不稳定、CPU低功耗检查RDP等级切换Under reset降低SWD速率Cannot erase memoryRDP Level 1/Level 2、Flash写保护先解除读保护再全片擦除Cannot connect / Connection error接线错误、供电异常、ST-Link固件旧换线、验证供电、升级ST-Link固件Device ID mismatch / 0x000000SWD信号问题、目标板未上电、复位电路异常检查NRST、SWDIO/SWCLK手动拉低复位再连RDP Level 2芯片最高级保护仅能通过Bootloader或更换芯片Cannot access targetTrustZone使能、调试端口被禁用查看TZEN位尝试System Bootloader模式Error: connection error 0xE2E0ST-Link非法命令或目标未响应降低频率用UR模式重试这张表并不是官方文档的精确定义而是我根据实际排障经验做的映射。拿“Cannot read memory”来说可能有五六种细微原因但表格里的优先级是我验证过概率最高的顺序。我在处理问题时习惯先排除硬件连接再排除保护位最后才怀疑芯片。因为怀疑芯片是成本最高也最不容易改变主意的方向往往浪费一两天后才发现只是Option Bytes没配置对。5.2 排查优先级如果你现在手头正好有一块连不上的WB55建议按这个顺序操作每一步都记录下现象避免重复操作确认板子供电正常测量3.3V稳定且在复位和射频发射时没有明显跌落。检查SWDIO、SWCLK、GND是否连接可靠是否使用过长导线。用STM32CubeProgrammer选择SWD、频率1MHz、Under reset模式尝试连接。如果连接成功先查看Option Bytes里的RDP、TZEN、BOR、Flash保护位。如果RDP为Level 1执行Remove protection允许全片擦除。如果连接失败尝试System Bootloader模式通过BOOT0引脚进入Bootloader再用UART/USB连接。擦除全片恢复默认配置重新验证。如果以上全部失败再考虑硬件层面的问题比如OXIDE损坏、晶振异常、焊盘短路。这套顺序我写进了团队的新人培训文档里目的就是防止新手一上来就“大力出奇迹”直接在GUI里乱点导致Option Bytes越弄越糟。有条理地记录每一步结果比盲目尝试几十种连法要快得多。6. 我的几点实操心得6.1 关于下载调试STM32WB55的调试体验比STM32F1系列要“矫情”不少。F1时代我随便拿四根杜邦线就能连WB55则对布线、复位和供电环境更敏感。尤其是自绘PCB建议SWDIO和SWCLK上各加一个33欧姆串联电阻靠近MCU放置能有效抑制振铃。如果产品空间允许再留一个测试点接到NRST救砖时会非常省事。另外WB55的M0核和M4核共享Flash但并非所有调试器都能同时良好支持。IAR较新版本对双核调试支持不错但如果你只是烧录用户应用建议在CubeProgrammer里选择“Erase sectors”而不是“Erase full chip”这样只擦除M4核应用所在扇区保留M0核的协议栈固件。不然你全片擦除后蓝牙协议栈固件也消失了重新下载BLE固件是另一套繁琐流程。6.2 关于低功耗这是我踩得最深的一个坑。WB55常用于低功耗场景工程师喜欢在代码里立刻进入Sleep模式或Stop模式。如果你调试时连接那一刻CPU正睡死SWD会经常无法建立稳定连接。不是说SWD不能唤醒CPU而是唤醒过程和调试端口仲裁的时序在特定条件下会冲突。后来我的习惯是开发阶段先把低功耗相关代码用宏关掉保证CPU一直活跃调试完再打开。如果产品需要验证真实低功耗行为我会在代码里加一个“调试模式”上电后等待10秒再进入低功耗给调试器充足时间连接。这样既不牺牲产品逻辑又保住了可调试性。遇到“插上ST-Link就正常拔掉就各种奇怪复位”的板子也优先检查是不是低功耗进入时序把调试引脚状态改变了。6.3 关于量产量产阶段遇到“cannot read, erased, programmed”最头疼因为板子数量多人工排查不现实。我的方案是在产线治具上固定使用STM32CubeProgrammer命令行脚本烧录前先执行一次Option Bytes检查确认RDP等级和TZEN状态。如果检测到非预期状态自动执行全片擦除和Option Bytes恢复再继续烧录。脚本里还要加入日志输出把每块板的序列号、MAC地址、烧录结果写进文件。这样一旦出现批量问题可以回头定位是连接异常、读保护状态异常还是Flash编程失败。我遇到过一批板子在产线上大概有3%连不上排查后确认是某批焊接物料导致SWCLK引脚虚焊而不是固件问题。如果没有日志和批量脚本这类问题会非常隐蔽。最后分享一个救砖小技巧如果你手上的WB55已经被折腾到“Under reset”也连不上的地步可以先尝试把ST-Link的SWD频率降到最低部分工具可以到几百kHz连接时按住板子复位键不放点击Connect后再松开。原理是让调试器在芯片复位释放的瞬间抢占调试端口这招对“固件启动后立刻改引脚功能”的板子特别有效。我个人在实际排查中还有一个小癖好每次连接前都先量一下SWDIO引脚对地电阻正常应该呈二极管特性大约0.5V压降。如果测出直接短路或高阻就不用浪费时间去查软件了先解决焊接问题。这个方法简单但很管用尤其在量产现场没有示波器的时候。毕竟STM32WB55这颗芯片本身并不容易坏绝大多数时候都是外围环境在制造问题找到它、解决它芯片自然就活了。