STM32移植USB驱动到RTX系统无法使用问题(USB分析/终篇)

前景提要

有了前面的问题解决经验，首先将模块里的malloc函数换成自己实现的接口函数，然后调整USB中断的等级，这些工作都做完之后，电脑也有了一点反应，识别到我的这个存储设备，但是就是不出现相应的磁盘。
同样的，打开调试，这次依旧是进入硬件错误中断，但是这次有所不同，是指向了os_dly_wait函数。

分析过程

然后又使用同样的手段，看看程序是由于哪一行的程序执行导致的，但是经过调试，发现每次程序死掉的时候，标志位都不一样，但是每一次都在一个可以找到的范围内。
最终锁定在这一部分，设置类配置信息这个函数出现的几率十分大，并且多次启动调试，全速运行，查看硬件错误指向的函数位置，很多次都指向SDIO模块中，可以看到是死的地方是使用DMA进行数据传输，并且是一直等待DMA传输完成，但是这里需要知道，这个函数是在USB中断中调用的，也就意味着在一个中断中开启另一个中断（SDIO DMA中断的优先级也是0）。

猜测是DMA中断的问题，通过宏定义将当前使用的通信模式改为查询模式，下载程序运行，电脑可以正常读取SD卡和NAND Flash。

移植主机的MSC设备时，依旧出现一些新的问题，虽然经过前面的修改，主机模式很顺利移植成功，但是，U盘在使用过程中仅有首次烧写成功后，才可正常识别，并写入文件，再次掉电上电后，U盘不再可以使用。
这个问题之前在硬件测试环节时，使用示波器进行测试时一旦探头碰到DM或DP引脚，显示屏就不再能够识别这个U盘，只有重新烧写才能够使用。
最一开始怀疑是由于我们的测试改变了flash里的程序，但是这个大胆而又可怕的想法很快就被排除了，因为这是不可能（因为程序还可以使用，不会那么巧每次都是USB不能使用，其他都很正常）。
既然可以很快复现，所以就开始调试运行，看问题出在哪里，前一段时间返回值都很正确。
但是经过一段时间（3分钟左右）之后文件拷贝结果就出现了错误码100，查看源码，可以看到是FatFS模块的代码，是由于申请缓存时，至少有一个申请失败导致的。

查看该文件系统模块的宏定义，可以发现当前使用缓存区时内部普通RAM区，猜测可能是由于资源竞争（内部RAM资源）所导致，将缓存区配置为外部SDRAM之后，经过很长一段时间之后，都没有出现前面出现的错误码。
但是，经过大概20分钟后，这个错误码再次出现，由此可以看出外部SDRAM出现错误的概率要比内部RAM出现的概率小很多。但是在此之后，重新上电U盘再也无法识别。
重新烧写程序，U盘又可以被成功识别，为了排除U盘是被错误情况下锁住（但是电脑依旧可以识别，这无法解释得通），将U盘拔掉后，再次重新烧写程序，然后再插上U盘，上电，U盘竟然依旧无法识别，由此可以看出，必须保证U盘是插在显示屏上（烧写程序时），这就很奇怪了，烧写程序的过程并不会对USB口写什么数据。
在这个过程中唯一提供的只是USB供电，然后就猜测是否是由于U盘在使用前需要保持上电一段时间，于是就复现之前的问题后，使用跳线帽（F429是低电平复位）短接J-Link（5pin）的后面两个引脚，将RESET复位脚和GND短接，进行复位（这个过程电源供电是没有关闭的），这时U盘又可以使用了。
为了更进一步验证这个现象，在初始化U盘之前添加一个延时函数（分别试过500ms、800ms、1s），最终发现这个U盘初始化之前需要在上电之后1s以上。
经过示波器测试，该显示屏从上电到电平稳定仅用了200us，所以不会是硬件USB电源供电不稳定，更换一个U盘后（或是一个读卡器）也就无此需求，可以看出这只是个别U盘所具有的现象，所以为了兼容大部分的U盘，在程序中还是应该考虑到这种情况（在后期使用过程中，支持热插拔，所以该问题不会影响使用，而且不需要单独为这一问题提供一个延时）。
到此，USB的主机（MSC）和从机（MSC和VCP）从逻辑移植到RTX过程中遇到的问题得到解决。

总结

本次USB移植过程遇到的问题，是由于：
1.HAL库中的实现所依赖的一个时钟滴答被RTX占用，而RTX未开源，所以只能在RTX任务中使用RTX留出的os_time；
2.USB的工作空间需求比较大，所以需要更大的系统堆栈大小；
3.由于RTX内部有使用标准库的malloc进行缓存的申请，而我们移植的USB模块内部也使用了标准库的malloc，而且还是在中断中使用的；
4.当前使用的系统中断和USB中断需要调至最高，否则会无法正常运行；
5.在中断中使用DMA（查询方式）进行数据传输会出现问题，可能是使用方式不对；