Echo之emmc初始化失败（CMD6问题）

文章目录

• • 目录

  • 文章目录

  • 概要

  • 问题分析流程

  • 查看emmc协议

  • 结论

    ---

概要

在调试自己写的emmc代码，发现测试佰维的emmc初始化识别，分析主要问题是emmc初始化中cmd6的出错

问题分析流程

1、从出错信息可以看到基本定位在emmc初始化时候发送cmd6切换8bit位宽后，下一次在发送配置mode命令（cmd6）出错。报err_interrupt，看协议是cmd超时。

2、确认硬件电路问题，该子板换了一块其他厂家emmc的子板工作正常。该片子在linux上启动是正常的。

3、是否是频率高了导致，降低emmc的clk以及cpu降频也是一样的问题

4、在发送切换8bit后延时100多us后再发命令没有问题。像是emmc接收8bit后没准备好？

5、如果发送切换8bit命令后，直接read命令读一次数据，再发送切换mode也没问题。

6、现象看发送cmd6切换8bit位宽后，不能连续在发送cmd6，得等会。

7、对比看几个emmc的的ext-csd寄存器有个cmd6的超时参数不一致。三星，东芝都是0xA（100ms） ，佰维的是0x5（50ms），不清楚这个参数带来的影响，厂家也在帮忙看。

8、目前看是代码兼容没做好：

上述几种测试可以的操作都是等待的意思。让下一次cmd6可以发送。不能连续发。

查看emmc协议

从协议上看

发送cmd6确实需要去发送cmd13去check。但是如果是busy的话 按道理其他cmd也不能发送，目前看就是cmd6有问题。

结合linux的代码每次发送cmd6也都有发送cmd13的步骤。

具体为什么佰维的这颗有问题，可能跟工艺有关？emmc处理cmd6比较慢？这是个人猜想，继续查看。。

结论

1、cmd6发送后都需要做个cmd13的发送来判断当前对端device的状态，才继续发送下一个cmd6.