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功能,开发工程师都没有理解这个东西,给以后的使用者埋下了一堆隐患。
### I2
### 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功能,开发工程师都没有理解这个东西,给以后的使用者埋下了一堆隐患。
### I2