从HackRF规划失误中，学习工程师Debug的思路！（下）
编辑:rootadmin
上回书说到，大量的HackRF被检查出“先天顽疾”——在生产的过程中，部分HackRF不能通过USB下载固件。而作者发现，似乎存在问题的板子，上面都有一个不能点亮的LED……
这个LED灯是用来指示HackRF的发射的。和想象中的有所不一样，这个LED直接地连接在了HackRF射频部分的电源上面。电源电压为3.3V时，LED完全导通；而当电源电压为1.5V以下时，LED完全截止。处于两者之间的电压都会使得LED微弱发光，但这样的电压不够以推动射频部分工作。为什么这样的状态就能使得Flash下载正常完成呢？经过一番搜索，我发现该部分电路理论上应该将供电VAA与总体电源Vcc断开，但在MOSFET上有时会透过一些微弱的电流。不管是移除控制VAA的MOS管Q3、滤波器FB2都能够使得不能烧写的问题消失，也就是说，如果你将射频部分完全断电，不能下载程序的问题就不存在了！——这听起来和我们一开始估计的“Flash芯片导致烧写错误”相距甚远，不过距离*越来越近了！控制MOS从而控制VAA的信号是低电平使能的VAA_ENABLE，它由单片机的一个GPIO口控制，用来控制这块软件定义*电板的射频部分。为了复现问题，我短暂地拉低这个引脚，问题便如期而至。看起来这个引脚的变化就是罪魁祸首，不过我仍搞不清楚为什么有些时候这个引脚会被启动。我将好板上的单片机和坏板上的单片机进行交换，问题依旧——看起来像是纯硬件的问题而非单片机的问题。我尝试着在VAA和VCC之间增加一个1千欧的电阻以部分充电VAA开关部分内的电容，大部分电路板都通过这种方式搞定了问题，但我仍未找到为什么VAA会被意外触发。为了调查这个问题，我在程序里再次布下Watch，观察GPIO寄存器以确定第一次触发GPIO写*作的程序位置——令我感到吃惊的是，第一次触发的位置并不是由厂商提供的DFU下载程序，而是我自己写的固件，在RAM中执行的程序指针位置。明明RAM已经被*了，为什么它还会执行？我忽然意识到，RAM被*可能只是漏洞所带来的结果，而非引发漏洞的原因！检查过自己的代码之后，现在我们就可以还原事情的*：在电路驱动的时候，初始化的过程会拉低VAA_ENABLE，使得射频部分的MOSFET导通，对后级C电容充电，这个过程会使得Vcc短暂地下降，而下降的幅度因板而异——实际上，在原型和前几批电路板中，这个问题都没有出现。当充电完成后，LED会完全亮起。但在这批板的某一些型号中，Vcc下降的幅度更多，使得单片机由于电压降的原因而重新启动，使得VAA_ENABLE信号被意外拉高，此时，C电容的充电不充分，LED会微弱地亮起。而此时，单片机的重新启动会使得RAM中部分数据遗失，造成了“RAM*导致了Flash下载失败”的假象。而当LED已经微弱亮起、电容部分充电后，再次手动重新启动单片机时，拉低VAA_ENABLE的*作的充电电流所造成的电压降就不会使得单片机再次重新启动。想搞定这个问题，首要的就是减少充电电流过大导致电压下降太多的问题。最终，HackRF的固件通过多次切换VAA_ENABLE，分批多次对电容小电流充电的方式搞定了这个问题。电子规划的迷人（烦人）之处正是如此，看上去针对某个器件的Bug的产生并不一定是这个器件本身的问题——甚至有可能都不是硬件的问题。搞定这样的问题一方面需要细心、另一方面也需要多做、多调、充分的调试经验和发散思维！本文为监听电*微信公众平台文章。详细内容及高清大图请查阅《*电》*。版权所有，欢迎个人转发至朋友圈。公众号、报刊等转载请联系授权。…………………………………………………
整理分享从HackRF规划失误中，学习工程师Debug的思路！（下） ，希望有所帮助，仅作参考，欢迎阅读内容。
内容相关其他词:,内容如对您有帮助，希望把内容链接给更多的朋友！
这个LED灯是用来指示HackRF的发射的。和想象中的有所不一样，这个LED直接地连接在了HackRF射频部分的电源上面。电源电压为3.3V时，LED完全导通；而当电源电压为1.5V以下时，LED完全截止。处于两者之间的电压都会使得LED微弱发光，但这样的电压不够以推动射频部分工作。为什么这样的状态就能使得Flash下载正常完成呢？经过一番搜索，我发现该部分电路理论上应该将供电VAA与总体电源Vcc断开，但在MOSFET上有时会透过一些微弱的电流。不管是移除控制VAA的MOS管Q3、滤波器FB2都能够使得不能烧写的问题消失，也就是说，如果你将射频部分完全断电，不能下载程序的问题就不存在了！——这听起来和我们一开始估计的“Flash芯片导致烧写错误”相距甚远，不过距离*越来越近了！控制MOS从而控制VAA的信号是低电平使能的VAA_ENABLE，它由单片机的一个GPIO口控制，用来控制这块软件定义*电板的射频部分。为了复现问题，我短暂地拉低这个引脚，问题便如期而至。看起来这个引脚的变化就是罪魁祸首，不过我仍搞不清楚为什么有些时候这个引脚会被启动。我将好板上的单片机和坏板上的单片机进行交换，问题依旧——看起来像是纯硬件的问题而非单片机的问题。我尝试着在VAA和VCC之间增加一个1千欧的电阻以部分充电VAA开关部分内的电容，大部分电路板都通过这种方式搞定了问题，但我仍未找到为什么VAA会被意外触发。为了调查这个问题，我在程序里再次布下Watch，观察GPIO寄存器以确定第一次触发GPIO写*作的程序位置——令我感到吃惊的是，第一次触发的位置并不是由厂商提供的DFU下载程序，而是我自己写的固件，在RAM中执行的程序指针位置。明明RAM已经被*了，为什么它还会执行？我忽然意识到，RAM被*可能只是漏洞所带来的结果，而非引发漏洞的原因！检查过自己的代码之后，现在我们就可以还原事情的*：在电路驱动的时候，初始化的过程会拉低VAA_ENABLE，使得射频部分的MOSFET导通，对后级C电容充电，这个过程会使得Vcc短暂地下降，而下降的幅度因板而异——实际上，在原型和前几批电路板中，这个问题都没有出现。当充电完成后，LED会完全亮起。但在这批板的某一些型号中，Vcc下降的幅度更多，使得单片机由于电压降的原因而重新启动，使得VAA_ENABLE信号被意外拉高，此时，C电容的充电不充分，LED会微弱地亮起。而此时，单片机的重新启动会使得RAM中部分数据遗失，造成了“RAM*导致了Flash下载失败”的假象。而当LED已经微弱亮起、电容部分充电后，再次手动重新启动单片机时，拉低VAA_ENABLE的*作的充电电流所造成的电压降就不会使得单片机再次重新启动。想搞定这个问题，首要的就是减少充电电流过大导致电压下降太多的问题。最终，HackRF的固件通过多次切换VAA_ENABLE，分批多次对电容小电流充电的方式搞定了这个问题。电子规划的迷人（烦人）之处正是如此，看上去针对某个器件的Bug的产生并不一定是这个器件本身的问题——甚至有可能都不是硬件的问题。搞定这样的问题一方面需要细心、另一方面也需要多做、多调、充分的调试经验和发散思维！本文为监听电*微信公众平台文章。详细内容及高清大图请查阅《*电》*。版权所有，欢迎个人转发至朋友圈。公众号、报刊等转载请联系授权。………………………………………………… 
