《TMP75温度传感器(I2C接口)温度值为-1的故障分析》由会员分享，可在线阅读，更多相关《TMP75温度传感器(I2C接口)温度值为-1的故障分析（7页珍藏版）》请在金锄头文库上搜索。
1、故障现象：平台软件在运行QNX系统的MLU板上每10秒读一次温度传感器，发现调用读温度的驱动接口函数时，偶尔读到的温度值为-1，但是接口函数的返回值为正常。读温度任务睡眠10秒通过sleep实现。该现象只在运行QNX的平台软件上可以复现，其它条件无法复现。故障分析：1在I2C总线驱动程序中添加打印信息，发现从CPU的I2C总线控制器中读回来的数据为OxFFFF（-1）。查看温度传感器芯片TMP75的数据手册，温度值由两个字节组成，根据配置精度，高8位表示整数部分（有符号），低8位中的高4位表示小数部分，低4位固定为0。因此可以断定OxFFFF属于总线上的异常数据。2阅读温度传感器的数据手册，发
2、现有如下描述：TIMEOUTFUNCTIONThsTMP175andTMP75willresettheserialinterfaceifeither3CLorSDAareheldlowfor54ms（typ）betweenaSTARTandSTOPcondition.TheTMP17SandTMP75willreleasethebusifitispulledlowsndwillwaitkirastartcordition.Thstim&outfunotionrequiiir&s.acommunicationspeedofatleast1kHzforSCLoperatingfnequency.如
3、果在一次数据传输过程中（传输start和传输stop之间）出现SCL或者SDA线被持续拉低超过54ms，那么TMP75将释放总线（将SDA置高电平）然后等待下一次传输start。也就是有可能总线上SCL或SDA出现了超过54ms的持续低电平，导致TMP75的TIMEOUTFUNCTION起作用，本应该传输正确数据的SDA线被置为常高，读到了0xFF。3为了验证TMP75的TIMEOUTFUNCTION功能，在I2C总线驱动程序中打桩，在寻址完成后读I2C总线控制器数据寄存器前主动增加延时，通过硬件测试程序观察读温度值是否正常。当延时小于50ms时，读温度正常，当延时增加到50ms以上时，可以稳
4、定复现读到-1的温度值的故障现象。同时让平台软件将调用读温度接口函数前后的时间差打印出来，确认当读到-1时，时间间隔达到了70ms左右，而正常时为12ms左右。因此平台软件读到-1的温度值的故障现象与在I2C驱动程序中主动增加延时造成的故障现象应该一致。4通过示波器抓读温度时I2C总线上的数据传输过程：用例1：如图1所示，正常读温度时从寻址完成到从设备开始传输数据的延时大约为1.1ms左右。以下所有波形，上面为SDA数据，下面为SCL时钟。AcqCompleteMPos:2.20msTRIGGER类型信源斜率IIIII繼合IIIIIIIIitI边沿CH2上升止常触发方式LI.，.J.I*丄CH
5、I2J0DVCH2flOVCH272241V26-May-1712:5210H;图1正常时一次完整的数据传输以下图2到图5是对图1的传输过程的放大和解析：信源耦合IIIiIIIITRIGGER类型CH2上升正常边沿斜率lekJL.AcqCompleteMPos:14.00ju$Lj_I_I_i_I_I_LCH12.00VI_I_L_IJ_|_I_I_l_CH22.00V直流M10.0JU5CH2Z2V26-May-1712:51：10Hz融发方式图2startcondition和寻址温度传感器0x90AcqCompleteMPos:103,6jusTRIGGER类型信源斜率耦合IIIIIIII
6、CH2上升正常流电就亠弋fi賞肺旷亠M1O-OjusCH272,24V26-May-1712:5110Hz触发方式图3寻址温度传感器寄存器0x0026-May-1712:55wvww边沿信漁斜率上升触发方式正常直流耦合I11丄B,丿IXi二、二丁.二匚由空诚工胞刘诫衲尬ti応t匝了26-May-1712:58|-1.02VgWidthHqeQty：41.423&amAM.DU扣eivzauwias.owiirprFravlewSingleSq10|ftSv-0EicqRt：*OkAiJldMiy3S-n2Q1iT汨丁:细ittAnMkiC(linto-*%Max工砂S6B|-3.K机01.4i
7、CTlMlnu1fi0.0wnV敌ifH.dliO.DwnI.C&Mansi.flTMpgg”36H|3.681.0Mlikdea.OtfnVdG0.naCO9indBO.ihn1.0CBMlnv-二?pz0.0GOMab7-D.C1图7延时40ms时可以读到正确的温度值0x3360用例3：在寻址完成到读温度值之间打桩增加延时到50ms时，抓到的总线波形如图8：1EQ.OmV3.6V-fio.amv3ir*gk5inReqsHX.1DkdHsfltBQCmVIM3:3DWT12DVfdiv1MQ务刼WMMMMMM二薰6p.aflDcS|S9.33S?ni3.5-aMB9flLaoDnncTSi
8、nPrflviflYF图8延时50ms时的I2C总线波形此时读到的温度值为-1，如图9，总线SDA上的数据出现异常，读到的数据为0xFFFF。-30DnOCTGiiiVAhiA1EQ.OVT1VD.QfnVMZdH抑协1酗3Oma/pi-1.92VPrflviewSir*ale-Sq-1.Q3VnRCHHL.4D.DhD.OV冒OflBBt:3QimIM3:300O2DWfdiv1UQSDDMi二6SEQ】widthHhh毗；1.瞿収日個弘图9延时50ms时读温度值异常0xFFFF5总结I2C主控制器在寻址完成并向从设备发送读命令，收到从设备返回的ACK后，不会主动发送SCL时钟信号，而是在驱
9、动程序读主控制器的数据寄存器时触发SCL时钟信号，从设备在检测到SCL时钟后开始传输数据。因此在寻址完成和读数据寄存器之间增加延时会导致SCL的低电平时间延长，当延时时间超过50ms时触发温度传感器TMP75的TIMEOUT功能，TMP75释放SDA不再传输有效数据，转而等待下一次传输重新开始。在QNX和VXWORKS驱动程序中增加延时，都可以复现上述现象。平台软件只在QNX下复现问题，不能在VXW0RKS下复现问题的原因是QNX的I2C驱动程序在轮询ACK时使用了usleep延时，每1ms轮询一次，而VXWORKS下的I2C驱动程序使用CPU定时器sysUsDelay进行延时。使用uslee
10、p进行延时会让任务主动进入睡眠态，增加了延时的不确定性，加上平台软件的任务延时也使用sleep，增加了任务调度的不确定性，读温度值为-1时刚好是平台软件任务最繁忙的时刻，而读温度的任务优先级最低，导致了任务延时超过50ms，出现数据异常。解决方案：（1）修改QNX的I2C驱动程序，参考VXWORKS驱动程序，将usleep延时改为使用sysUsDelay进行延时。同时判断读到的温度值的第2个字节低4位是否为0（TMP75明确第2个字节的低4位固定为0）,若不为0则数据非法，返回错误。（2）平台软件在读温度时，使用释放信号量的调度方式，在系统任务空闲时调度读温度任务。检查了EEPROM和RTC时钟芯片的数据手册，没有类似的TIMEOUTFUNCTION，同时也进行了延时操作的打桩测试，没有发现读数据错误的情况。
