最近鱼鹰一直在 docker + yocto + vscode + openocd 环境下开发 STM32H7，利用课程里面的 dockerfile，很顺利的就在 yocto 环境里面支持了 jlink、stlink、daplink 调试器，可以方便快捷的实现 vscode 下单步源码调试 mcu，相比串口打印，效率提高不少。
即使是打印，也要考虑串口模块是否有问题，串口驱动是否正常，是否漏数据，因此鱼鹰开发时一直首选在线调试，打印只作为辅助。
本来在容器环境下，openocd 调试非常正常，但是出差回来发现，公司的几块开发板都没法调试了，而一块全新的板子没有这种问题。
一直报下面这种错误：
可以读取 ID，说明连线时正常的。
这让鱼鹰百思不得其解，没道理芯片损坏才对，因为我可以通过 ST-LINK Utility 工具下载，就是这货（老古董了）：
但是在 linux + openocd 环境下就不行。
问 AI，也是各种怀疑点，试了不行，只有一个点在后面证明算是说到关键点了：选项字节。
不过因为时间原因，一直没去验证，因为个人觉得，公司除了我，不会有人动这块内容（现在鱼鹰也不知道为什么会被修改，下载的固件都差不多）。
两颗芯片表现是一样的，都是 ST-LINK Utility 工具正常下载，后面测试了 J-flash，也能下载。后面又通过 MDK 本身调用 st-link、dap、jlink 调试器，都不行！
这说明，和硬件调试工具没关系，和上位机有关系。
鱼鹰也测试了网上的 dap 上位机，也是不行。
老牌专业上位机就是牛。
后面专门对比两颗不同表现芯片的选项字节，果然发现了不同：
默认上述都是勾选的，但是有问题的芯片，nRST_STDBY_D1、nRST_STOP_D1、IWDG1 都没勾选。
原以为是前两个选项导致调试失败，最终发现，起作用的是 IWDG1，当它没勾选时，MDK 都下载不了，openocd 更没戏。
我们可以看看这个bit的说明：
也就是说，如果看门狗由硬件控制，一切都好说，一旦变成软件控制，MDK 都不好使。
这里到底是什么原因，为什么专业上位机可以在这种情况下载成功，可能需要鱼鹰后续好好研究一下了。
老牌下载工具还是有很多值得学习的点。