MXL608是MaxLinear的一款tuner产品,支持DVB-C/DVB-T/DVB-T2/ATSC/ISDB-T等制式应用,这款芯片的调试工作占用了我2017年一个多月的时间,先是给客户调试linux和ecos驱动花了大半个月,弄了一个临时解决方案,后来领导想在公版方案彻底解决这个问题,又把我拖进去搞了半个月。中间找了很多人都没办法搞定,还好我最后灵光一闪,找到了问题的根本点,也算是2017年比较大的一个成就吧。在我看来,MXL608这个芯片确实做得很烂,原厂的驱动代码也写得很烂,下边我就谈谈这个芯片的问题和经验教训.
### MXL608有那些坑
1.芯片硬复位异常,芯片很容易挂掉,只能软复位
2.683的ts输出没有高阻状态,主芯片使用内置demod的时候,需要683的ts输出高阻才能避免信号干扰。没办法,这个时候只能把683 disable掉,用的时候重新初始化。
3.683如果没有正常初始化,会响应其他设备地址的信号并把总线拉低,导致i2c死锁。
4.683需要下载固件,原厂的驱动代码直接把几十k的固件写成一个局部变量,像ecos这种堆栈空间大的跑起来没问题,linux内核这种函数堆栈很小的系统,一跑就挂了。
5.683有clock stretching功能,这个功能原厂支持的人居然也不知道,参考手册里边也没有说明,而且手册有个地方很奇怪,读数据的时候,写完寄存器地址需要等500ms才能再读数据,处理完这个问题之后回头看这个地方,明显是为了规避clock stretching功能,开发工程师都没有理解这个东西,给以后的使用者埋下了一堆隐患。
### I2C的clock stretching怎么回事
时钟拉伸是I2C协议的一个标准,它允许从设备来不及响应主设备请求的时候主动拉低总线,等数据处理完在释放总线。就是说主设备向从设备读数据,主设备发完地址,从设备说我给你数据需要时间,我先把总线拉低,等我数据准备好了再释放。然而这个功能需要主从设备都支持才行,很多I2C控制器都没有实现时钟拉伸,比如说我们的主芯片就没有,这个时候会导致什么问题呢?主设备并不知道总线被拉低了,所以会继续读取数据,导致读取到的数据都是0。读完之后又发起下一次请求,这个时候683就会
### MXL608有那些坑
1.芯片硬复位异常,芯片很容易挂掉,只能软复位
2.683的ts输出没有高阻状态,主芯片使用内置demod的时候,需要683的ts输出高阻才能避免信号干扰。没办法,这个时候只能把683 disable掉,用的时候重新初始化。
3.683如果没有正常初始化,会响应其他设备地址的信号并把总线拉低,导致i2c死锁。
4.683需要下载固件,原厂的驱动代码直接把几十k的固件写成一个局部变量,像ecos这种堆栈空间大的跑起来没问题,linux内核这种函数堆栈很小的系统,一跑就挂了。
5.683有clock stretching功能,这个功能原厂支持的人居然也不知道,参考手册里边也没有说明,而且手册有个地方很奇怪,读数据的时候,写完寄存器地址需要等500ms才能再读数据,处理完这个问题之后回头看这个地方,明显是为了规避clock stretching功能,开发工程师都没有理解这个东西,给以后的使用者埋下了一堆隐患。
### I2C的clock stretching怎么回事
时钟拉伸是I2C协议的一个标准,它允许从设备来不及响应主设备请求的时候主动拉低总线,等数据处理完在释放总线。就是说主设备向从设备读数据,主设备发完地址,从设备说我给你数据需要时间,我先把总线拉低,等我数据准备好了再释放。然而这个功能需要主从设备都支持才行,很多I2C控制器都没有实现时钟拉伸,比如说我们的主芯片就没有,这个时候会导致什么问题呢?主设备并不知道总线被拉低了,所以会继续读取数据,导致读取到的数据都是0。读完之后又发起下一次请求,这个时候683就会