基于DWC_ether_qos的以太网驱动开发-软复位介绍与问题案例

一.前言

一般模块都会有软复位的功能,软复位在驱动编写中很重要。一般初始化时执行软复位使得模块进入确定的初始状态以提高可靠性，异常时也可以重新初始化来恢复，所以软复位在驱动中一般是必须要做的动作。对应复杂的IP其复位过程其实是很复杂的，有很多前提和依赖，对于驱动编写来说也有一些需要注意的地方甚至是有一些坑，所以本篇单独来讲讲DWC_ether_qos的软复位。如果你有遇到DWC_ether_qos软复位的问题，建议可以看看本文章，说不定就有你的问题的答案!

二.DWC_ether_qos的软复位

软复位的作用简单的可以总结为复位控制逻辑(比如状态机等)，和相关的资源(比如寄存器值恢复到默认状态等)。

DWC_ether_qos的软复位参考手册P1013，偏移0x1000的寄存器DMA_Mode寄存器的位0,SWR的解释。

从以上描述可以看出其实信息量是很多的，换句话说需要注意的地方是很多的，以下做一个总结

1.触发软复位,MAC和DMA控制器会复位DMA，MTL，MAC这几个子系统的内部逻辑和相关寄存器。

2.该位是自清零的，即软件写1触发软复位，硬件复位完成清零。

3.必须等到DWC_ether_qos所有的时钟域都完成复位才会完成，才会清零该位。

4.该位为0之前，即为1时不能写DWC_ether_qos的任何寄存器。

5. 该位置位后，不能立马去回读该位，需要等待4个CSR周期后才能读 ，因为状态更新需要时间(具体的原因就涉及具体的总线协议了)。这里是驱动编写的一个容易掉坑的地方需要注意。立即读可能读出0认为复位完成了(实际复位还未完成)马上去操作其他寄存器会导致不可预知结果，这种结果是随机的导致的现象更可能是随机加随机。
6. 复位需要PHY的所有input时钟比如RXC有效 ，这一点也是驱动编写容易掉坑的地方，如果RXC引脚映射错误，PHY未就绪，都可以导致没有RXC时钟而不能完成复位。如果你遇到不能软复位的问题第一步就查这里吧!
7. 复位完成时间是不确定的 ，需要等到所有时钟域完成复位才算，所以要等最慢的那个完成才算。底层接口最好只提供set_rst和get_rst两个接口，由上层去调用该两个接口实现等待查询操作。因为时间不定，所以调用者可以使用线程等待，超时重试等处理，而如果底层接口使用指令死等则效率太低，会占用CPU，并且也不知道设置死等多长时间合适(指令死等时间受主频等影响，使用定时器则需要占用硬件外设且不具备可移植性)。

三.软复位不能完成的案例

我驱动开发时就遇到过不能软复位的案例，后面调试发现一个是RXC引脚映射错误导致的，另外一个就是PHY没有输出RXC的时钟导致的，所以如果你遇到类似问题先查上述原因吧。

另外触发复位后等待4个CSR时钟以上再去查询这点也很重要，因为这个很可能导致随机问题，也就是你可能立马回读读到的是1，那么继续等待为0复位完成，没问题。也可能是立马读到0，没有复位你认为复位了继续去操作寄存器，此时操作寄存器操作行为不可预料。所以很可能导致随机异常，并且很难定位。这个时候你可能会遇到白天有问题，晚上没问题(因为温度导致读写时序细微差异可能导致立马回读的状态不一样)，重新编译一下运行有问题，再重新编译一下运行没问题，加个打印有问题，去掉又没问题等各种诡异的问题，此时你可能会觉得这是神学了，只能烧香拜佛了。实际上任何问题都有确定的原因的只是你不知道而已，所以驱动开发者遇到问题从来不说神学，也从来不瞎试，而是从原理分析，看手册，梳理原理，梳理路径，反推，测信号，逐步推进等方式去定位根本原因。这就是驱动开发与一般开发的区别。如果还找不到原因，上厕所时翻翻手册吧，你可能会有所发现。随手翻手册，手册当小说看，是驱动开发的必备素养，基本上我每开发一个IP驱动，至少手册的所有文字都要看一遍以上，尤其是标注*号的，note的，其他就是各个模块调试时详读具体章节加翻阅，寄存器至少是每一个寄存器的每一个bit都要看一遍的。当然开发阶段熟读手册，勘误手册，积累，多调试不通配置的效果等很重要，这样才可能遇到问题知道查哪，才有可能上厕所时灵感迸发。

四.总结

驱动开发需要注重细节，了解原理很重要，手册一定要熟读，经验积累也很重要，一定要充分调试各个功能，多去尝试不同配置对应的不同效果。