BUG Report-1
WIFI芯片端26M CLOCK存在跳动
ü Test condition: openhone_pcb_v1.0.0上只开WIFI,关闭BT
ü WIFI芯片(bcm4343)端26M CLOCK存在跳动的现象,有直流信号耦合进来。
ü 进一步测试发现26M 会随着CLK_REQ跳动。
CLK_REQ为低电平时, 26M从-0.25v到0.75V
CLK_REQ为高电平时, 26M从0.1v到1.1v
使用TCXO的方案现象依然存在, 由于输出端有隔直电容,26M跳动确认由bcm4343引起
检查电源无异常
在正常模式下:无论CKL_REQ为高低电平的时候, VDDRF0和VDDWRF都有1.8V左右电压。
在DEEP SLEEP模式下:
CKL_REQ为高电平, VDDRF0和VDDWRF有1.8V左右电压输出。
CKL_REQ为低电平, VDDRF0和VDDWRF无电压输出。
由以上可知: VDDRF0和VDDWRF与CLK_REQ的关系配置正确。
博通表示:bcm4343需要从0.1v到1.1v的26M时钟,在clk _req高电平时有效即可,且在高电平时必须有效,低电平时26M有没有对bcm4343不影响
产线测试SPI fail 问题
前言:
为了在生产后能够揪出失效或者半失效的芯片,就会在设计时加入专门的测试电路,比如模拟里面的testmux,数字里面的scan chain(测逻辑),mbist(测存储),boundry scan(测io及binding),来保证交付到客户手上的都是ok的芯片,我们产线测试的一项就是在Test mode下通过FDMA进行读写,FDMA使用的通信接口就是SPI
ATE负责的项目非常之多,而且有很强的逻辑关联性。测试必须按顺序进行,针对前列的测试结果,后列的测试项目可能会被跳过。这些项目的内容属于公司机密,比如电源检测,管脚DC检测,测试逻辑(一般是JTAG)检测,burn-in,物理连接PHY检测,IP内部检测(包括Scan,BIST,Function等),IP的IO检测(比如DDR,SATA,PLL,PCIE,Display等),辅助功能检测(比如热力学特性,熔断等)。
问题:
产线测试发现SPI通信异常,STLinit后0054寄存器读出值应该是0x9870,但是大量芯片读出0000和FFFF
分析:
对比正常和异常的芯片,正常的机器在FPGA输出地址后(DI),Marlin立马输出数据(DO),而不正常的机器在FPGA输出地址信息后,芯片没有任何响应。
对比了下正常芯片和不正常芯片的DI的建立时间,均为310ns左右,无明显差异。
Asic的同事怀疑是焊接问题导致spi无输出,因为他们有一片问题芯片磨平后重新植球就是正常的,所以猜测是焊接不良导致。大家做了一下几个实验:
封装的同事确认下封装厂是不是可靠,有没有可能是芯片内部打线的问题。
重新对问题芯片植球后确认是否ok
我这边针对正常和问题芯片进行二极管特性的测试来排查焊接的问题
等系统板做好后找软件同事在大系统下配置芯片的spi为gpio拉高拉低来确认是不是物理连接问题导致。
实验结果:
1.照x光确认ok
2.重新植球后大部分not ok
3.正常芯片和不正常芯片在不开机状态下的二极管特性是一致的,上电在fpga初始化marlin后,spi状态对比只有DO有差异,正常的这时阻抗为60ohm,而不正常的阻抗无穷大。
4. 用jtag连系统板,下载配置文件后配置为gpio拉高拉低输出方波均正常。
最后发现原理图上芯片的四个控制信号有四个电阻,而有两个默认拉低,另外两个悬空,最后翻阅pinlist发现测试模式总共有16总,分别对应4个控制 信号的16个逻辑组合。目前状态有四个组合,而只有一种组合spi接口是配置为spi功能的,而其他组合都不是spi功能。
结论:
由于fpga给芯片的几个控制信号的链路不通导致芯片没有正常的工作在spi模式,所以spi没有正常通信。
得到一个教训:接口通信不正常,特别是什么信号都没有时可以大胆猜测物理引脚是否配置为当前的接口模式,熟悉系统的配置有利于整体解决类似问题。
Camera bring up报告
问题:
Camera (OV5670)无法点亮,I2C identify成功,打开Camera有MIPI信号输出,但CSI侧不能接收到MIPI数据。
分析:
观察MIPI波形,发现CLKp/n、DATA0p/n在LP状态下高电平都在1.5V,而正常的电平应该是1.2V。后发现是由于Camera的DVDD供电(1.5V)有误导致,改为1.2V供电后,CLKp/n、DATA0p/n在LP状态下的高电平正常,但Camera 仍无法点亮。
仔细观察DATA0p/n的波形,发现MIPI数据刚开始传输时,CSI侧的端接电阻没有打开,数据传输了一段时间后,端接电阻才打开。
怀疑开始时端接电阻没打开,是由于CSI侧配置没有完成导致。CSI的协议要求发送端发送数据前,接收端必须先处于Ready的状态,如果在发送过程中去初始化接收端的CSI则会导致接收不到数据。
软件通过将代码中Sensor初始化完成后的“stream on状态”改为“stream off状态”,Delay Sensor输出MIPI信号的时间。MIPI数据开始传输时,CSI侧的端接电阻已打开,且Camera能正常点亮。
Core prime ap lockup 问题分析报告
问题:
有一台机器软件告知进校准模式后必现cp crash问题。
分析:
由于chip sleep信号没有测试点,所以在问题机器上对 NFD10 /B8 pin,用adb命令关联到AP deep sleep上,对比vddarm唤醒时的上电时序参考chip sleep和正常时一致。
加大chip sleep后arm 上电后系统响应的 delay没有效果。
使用VDDARM掉电,而里面CA7 TOP和CA7 C0 不掉电,没有效果。
使VDDARM不掉电,确认问题不再出现,但是在VBAT上会增加2.0ma+的低电流。
关闭DVFS,提高VDDARM 电压到1V,仍然唤不醒。
dcdc arm slp in slp out调整,没有效果。
调高VDDCORE到1.0V,没有效果
VDDCORE不降压,没有效果
关闭PHY 掉电,没有效果
调高VDDCORE到1.0V,且deep sleep不降压,没有效果。
从以上实验判断VDD_ARM 的供电和D die AP 的打开应该是满足先后顺序的。
而后北京的同事播放FM出现睡眠后唤不醒,且增加两行代码使AP-SYS不掉电后,便没有复现唤不醒问题。借鉴这个经验在问题手机上做同样操作后也正常。
分析AP的AHB是挂到ap sys上的,这也就是说ap sys如果不掉电,ap起来就能跑上mpll的较高频率上,但是已经有了软件workaround的方法,asic也没有继续往下查
马达低温下不工作
问题:
环境:在低温-20℃下,进sleep约2小时后,进行功能测试,有时马达不能工作
分析:
测试发现故障时,马达电压0.4v,工作电压3.3V
在低温-20℃时,测量马达阻抗,阻抗从常温33欧姆变化到低温10欧姆左右。换句话说,此时驱动马达的LDO输出和GND之间的阻抗变低了,有可能过流
查阅LDO的spec发现,输出电压在0.4v以下,是触发了短路保护,短路保护后输出电流为40mA。关闭短路保护后马达可以正常工作。短路关闭后,过流保护仍然可以工作,限流在400ma,风险较低
开机sleep后无法唤醒调试报告
问题:
手机开机后大约8s左右手机定屏,按键无任何反应
分析:
手机板上做IC交叉实验,问题跟着IC走,说明是IC的问题
测量时钟发现,Transceiver在进入low current mode后,DCXO停振。从而导致无32K clock,系统无法工作。(时钟方案是transceiver接26M后输出时钟)
通过短按Power key进入low current,发现不同芯片有不同表现。
用不同的软件版本,也有不同的结果。
XOP amplitude |
短按PBINT |
SW 17.10.3 Sleep mode |
最新版本 Sleep mode |
Bad chip1 |
正常,幅度下降 |
正常,幅度下降 |
停振 |
Bad chip2 |
幅度不变 |
幅度不变 |
停振 |
Bad chip3 |
停振 |
停振 |
停振 |
Good chip |
正常,幅度下降 |
正常,幅度下降 |
正常,幅度下降 |
Ø 鉴于之间的经验,初步怀疑为驱动能力不够导致晶体停振,实验:
1. 通过配置Transceiver寄存器的方式,提高Low current mode下的晶体驱动能力。
2. 把CDAC(容性 DAC, 或称为 CDAC)调为0
3. 更换ESR(等效串联电阻)较小的晶体
上述实验均没有效果,说明不是驱动能力导致的。
Ø 怀疑是否为电源的问题,跌落或者带载能力不足。实验:
1. 外灌VDDDCXO ------ 没有效果。
2. 关闭VDDDCXO low power mode ------ 没有效果
3. 外灌VDDRF0 ------ 没有效果
4. 在VDDDCXO外加负载,故意拉低VDDDCXO电压 -----开机后不再发生停震现象
Ø 为什么有些芯片短按Power Key晶体不会停振,而开机后再进入low current mode会停振?且SW 17.10.3版本也不会停振。
Ø 软件同事逐步排查版本之间的差别,发现改动为:VDDDCXO从1.8V 升压到1.95V (符合上一步在VDDDCXO上拉负载,故意降低输出电压的结果)实验:
1. 短按Power Key后,外灌1.95V VDDDCXO,发现晶体停振
2. 软件去除VDDDCXO升压Patch,和短按现象一致。
说明VDDDCXO不同的电压值,芯片有不同的表现。
实验:
1. 去掉DCXO后,在XOP脚外灌26M Clock,依然能复现问题。
2. 外灌26M clock的同时,测量32K clock,发现32K clock依然会丢失。
3. 使用DCXO,将32K clock的源切为RC,发现手机工作正常,32K有输出。
Tranceiver有两个关于clock 的控制信号:DCXO_EXTRA_LOWI_EN,CLK32K_MODE.
从下表中可以看出,当DCXO_EXTRA_LOWI_EN,CLK32K_MODE同时为高时,transceiver会关闭输出。所以怀疑IC内部信号有短路。
结合ASIC内部电路和仿真结果更进一步推测信号可能发生短路:
1. 如图所示 ,Low-current-mode和Extra-low-current-mode管脚输出为P+Nmosfet结构,GSM输入端是比较器架构
2. ASIC仿真结果是,Extra-low-current-mode Nmosfet驱动能力比Pmosfet强,所以红色部分一旦发生短路,输出的电平会低于0.9V(1.8V/2),典型值为600mv ,且VDDDCXO上的电流为550uA
EX: mosfet相关:
NMOS的特性,Vgs大于一定的值就会导通,适合用于源极接地时的情况(低端驱动),只要栅极电压达到4V或10V就可以了。
PMOS的特性,Vgs小于一定的值就会导通,适合用于源极接VCC时的情况(高端驱动)。但是,虽然PMOS可以很方便地用作高端驱动,但由于导通电阻大,价格贵,替换种类少等原因,在高端驱动中,通常还是使用NMOS。
为了检查DCXO_EXTRA_LOWI_EN 和 CLK32K_MODE是否真的短路,又由于芯片没有出ball,所以需要做芯片DeCap分析。需要测量的信号如下图:
DeCap分析结果:
1. 短按PBINT后, DCXO_EXTRA_LOWI_EN 和 CLK32K_MODE的信号高值为524.8mV,正常DCXO_EXTRA_LOWI_EN应为0V, CLK32K_MODE 应为1.8V。
2. 开机进入low current mode后,高值为626.3mV,正常DCXO_EXTRA_LOWI_EN应为0V,CLK32K_MODE 应为1.95V。
用万用表分段测量阻抗,寻找短路位置:
1. 下图中的红线部分的bonding线剪断,分别测量①②③位置处信号间的阻抗。
2. 测量发现①处短路,②处正常,③处正常
确定DCXO_EXTRA_LOWI_EN 和 CLK32K_MODE 短路,由于① 处的bonding线还和D-Die连接,还不能断定是线短路还是Die短路,Die测量结果证实Die正常,没有短路,由此断定①处bonding线短路,用3D X-ray也证实Bonding线短路
结论:
芯片内部DCXO_EXTRA_LOWI_EN和 CLK32K_MODE Bonding线短路导致系统在进入low current mode 时,错误的进入到Extra low current mode. 从而系统无32k clock,导致无法正常工作。
解决措施
l ATE筛选方案局限性
1. 发生短路的信号并没有出ball,这对ATE筛选带来了很大的难度
2. 芯片只能工作在P-test模式下
3. 是SIP方案,各个模块都独立进行测试
l 所以必须从已经出ball的信号进行间接性的筛选
l 结合ASIC仿真结果以及实验实际测试的数据,将各个模块联动起来,从已出ball的信号间接性的进行筛选,筛选步骤如下
1. EVB上让A-die进入PTEST mode
2. 采取时钟外灌方式,分别外灌32K给Adie ,26M给Ddie
3. 上电后通过Ddie写Adie寄存器,让Adie强制将low-current-mode拉高
4. 外灌1.9V或更高的电压到VDDDCXO
5. 断开外灌的26M
6. 测量VDDDCXO上的电流
正常芯片:100+uA
异常芯片:600uA左右
蓝牙打开异常问题分析报告
问题:
故障机必现,单板测试发现蓝牙打不开
分析:
按照如上流程检查,从log来看是UART通信Fail,AP没有收到ACK
正常机器的流程如下
打开BT—电源域上电—RST WCN—AP发送0x7E给到WCN--WCN发送0x55到AP准备通信(全双工通信)—WCN收到之前AP发送的0x7E后,回复0x7E—开始通信
异常机器在走到WCN发送0x55那里就停了,AP没有收到0x7E的回复
AP TX的波特率
为什么波特率会异常呢,对时钟源进行排查,发现PLL在启动阶段就出现了异常,根源在RPLL
1. UART input CLK #3point(TDPLL output) : 38M(normal 48M)
2. WPLL output CLK #2point : 41M(normal 52M)
3. RPLL output CLK #1point : 20.8M(normal 26M)
抓取RPLL在启动过程中的变化如下,可见是在DSP启动以后,RPLL发生了异常,随后实网后重新设置正常
软件分析:我们发现Chipram在DSP启动之前没有启用RPLL0_CFG CLK,如果我们在Chipram启动阶段启用CLK,那么在DSP启动时RMA芯片RPLL将正常工作
Root cause: this is low failure rate issue, for RPLL N/K did not load to the right setting when DSP initiation for the Detector has marginal setup/hold timing window, the occurrence rate is very low:
RPLLCLK =26M*32/32=26M or 26M*40/40=26M(default normally )
RPLLCLK=26m*32/40=20.8(N/Kdid not load to 40 for detector fail by marginal timing, keep 32; POSTDIV had load to 40 for no timing requirement)