前面是脱水版：
下面的日志记录了一个无辜的嵌入式工程师因为一个小问题调了一下午bug的悲惨经历，生动形象的表现了嵌入式工程师同时调软件和硬件的苦逼生活，很容易查半天软件发现是硬件问题或者反过来。
在这个充满着bug的行业里，经验正是这样一次次中积累起来的。
自己捣鼓跨平台下的编译工具链从来就不是什么太简单的事情，这不，今天又蹦出来开开心心写完的程序烧不进芯片的问题。
最开始是SystemWorkbench里debug的时候提示vFlash擦写失败，自然而然就想到是不是之前在用mini-m4板子时候遇到的买来的板子里芯片的flash已经被锁住了的问题，所以开始准备用openOCD单独打开调试模式查看问题。
中途的插曲是自己太久没有用OpenOCD调试，一时间忘了怎么设置配置文件的查找路径，调了半天一直报找不到对应的cfg文件的错误。自己又是重新下OpenOCD又是找网上的各种答疑找了半天，最后发现通过-s命令定义下查找范围就好了：
openocd -s ..\share\openocd\scripts -f Robotics.cfg
千辛万苦总算连上了板子，结果又发现不是如stackoverflow上STM32 Read-out protection via OpenOCD问题里解开芯片锁就解决了这么简单，因为在reset halt一步以及就卡住了，直接提示halt timeout。
这就斯巴达了……
最开始怀疑是不是芯片是坏的，或者直接烧了，然后赶紧断了电查了一通。查着查着想起来，要是真是坏了岂不是会是id什么的都现实不出来，怎么可能还有反馈。这里自然就怀疑到硬件组没有画nRST线，赶紧搜一搜，发现SW4STM32的论坛上有个问题的回答里真还谈到了这个问题，而且解决方案只需要把
reset_config srst_only srst_nogate
里的srst_only硬重启删掉就好。
赶紧试一试立即就可以了，谢天谢地…这个避免了我给TL汇报程序烧进去了结果烧不进去还要硬件组返工的牛皮吹破的窘境。