usb_tuning工具的调试总结

        此工具是原本是uart接口，后为了省内存改为usb。tuning工具是python写的图形化窗口交互工具，用来给用户获取修改isp和3a参数，交互方式有敲命令、拖动滑条和点击标签。

在调试过程中下位机arm程序出现的几个问题

1.程序运行中出现异常

        一开始用trace32追踪，只能查出程序是在dev->send指针处出现预取指中止，发现send函数指针的值被改成0xcdcdcdcd，至此只能判断是内存覆盖。于是在send变量的内存处设置内存写断点，后来在usb驱动里面某处停下来了，这是一句函数调用，用来往pdata指向的内存写入上位机发送过来的数据，这样就知道send指针的值是在这里被改写的，pdata指向的地址经过了send内存，send的内容被覆盖。这些工作还只是弄清了现象的直接原因。必须查到根本原因才能解掉这个bug。

        pdata指向一个堆空间，用以把上位机发送的数据存储在堆里。于是我把pdata的值print出来，转而把send的值也print出来，最后发现随着pdata的递增，指向的地址越来越靠近send的内存地址。真相渐渐清晰了，send变量也被分配在堆里，而pdata也指向堆。分析代码后发现send是一个device结构体的成员，而所有的device结构体都用链表的形式用calloc函数存储在了堆里。而我们的堆空间极其有限只有4096个字节。

        最后改用数组存储usb数据了，问题得以解决。

2.程序跑飞，停不下来

        这是继第一个bug解掉之后的第二个问题。上位机发送isp filter read命令后，得不到下位机的反馈，当我想break时，发现程序停不下来，显然已经跑飞了。

        然后我通过print log缩小问题出现的范围，最后发现在读isp寄存器的时候跑飞了，用jtag的dump功能查看内存发现也查看不了，然后确定是isp模块没有工作，读寄存器导致跑飞。

3.上位机偶尔收不到下位机的数据

        这个情况是偶尔的，最后发现是arm没有接收完上位机的完整一条命令（分多次中断接收），我就开始usb write了，没有做好错误处理。

总结

        调试是程序员很重要的一部分内容，要善于运用多种调试工具和手段，区分不同调试工具和手段的局限性，从而选择最合理的。在调试中，程序员的思维也很重要，严防掉进不重要的细节陷阱，关注最重要的地方。仅仅凭经验调试是走不远的，思路也很重要。