Secuencia de arranque de MMC/eMMC

He estado tratando de conectar un chip eMMC a un FPGA, que recibe comandos a través de un microcontrolador para inicializar y activar operaciones de escritura/lectura en sectores determinados.

Tengo problemas con la secuencia de arranque de la MMC que estoy usando, sigo los estándares que encontrarás aquí o aquí si no quieres crear una cuenta en JEDEC . El documento es bastante denso y estoy un poco confundido. Esto es lo que hago por ahora:

  1. Inicio: MMC está cronometrado, la línea CMD está bajada
  2. En la acción del usuario, envíe CMD0 0x00 a través de CMD, es un comando de 48 bits de ancho creado así: cmd <= "01" & CMD0 & STUFF_BITS32 & "1001010" & '1';(Consulte la página 145/352 del archivo pdf anterior). Este es el comando GO_IDLE_STATE. No se espera respuesta.
  3. En la acción del usuario, envíe CMD1 0x80FF8080. Construido como el comando anterior, excepto que CRC7 es 0010110. Este es el comando SEND_OP_COND, que debería enviar datos a través de la línea CMD.
  4. En la acción del usuario, envíe CMD2 0x00. Construido como el comando anterior, excepto que CRC7 es 1100001. Este es el comando ALL_SEND_CID, que debe enviar datos a través de la línea CMD.

El problema es que no recibo ningún dato. ¿Alguna idea de lo que estoy haciendo mal?

Consulte a continuación las capturas de un analizador lógico;Enviando CMD0 Enviando CMD1

Información adicional: Por ahora he conectado una tarjeta Transcend MMCPlus de 1GB, siguiendo los pinouts que he encontrado en línea . Todavía no he conectado las líneas de datos. Estoy calculando el CRC7 con la información proporcionada en la página 254/352 (8.2.1). El reloj MMC se divide 32 veces de mi reloj en chip de 12 MHz, lo que lo convierte en ~ 375 kHz por ahora (planificando acelerarlo después de que la inicialización tenga éxito)

Respuestas (2)

Tengo el mismo problema, aunque el host es ARM MPU. Sin embargo, creo que la línea CMD debe activarse de forma predeterminada, como dice mi guía de diseño de eMMC:

"R CMD_PU: se debe conectar una resistencia pull-up de 10K ohmios a la señal CMD para evitar que el bus flote".

Tienes toda la razón, tirar de CMD hacia abajo al inicio durante el tiempo suficiente para alternar una operación de arranque diferente. Tuve que agregar esto a las restricciones de mi diseño y ahora está respondiendo
Todavía tengo problemas (sin respuesta para CMD1). ¿Podría ayudar a publicar mi pregunta en ks0ze ya que no puedo comentar su respuesta? Estoy usando eMMC de 8 GB con alimentación y bus operados a 3,3 V, y no a 1,8 V. En ese caso, ¿la carga útil de CMD1 será C0FF80 0 0 en lugar de C0FF80 8 0, ya que el bit [7] de OCR para 1,8 V no está disponible? ¡Gracias!
De cualquier manera, debe obtener una respuesta del eMMC. Me encontré probando con 0x0000 como argumento para CMD1, y el eMMC aún responde en mi configuración actual. El bit de ocupado permanece bajo, lo cual es incorrecto, pero se está comunicando. Sin embargo, permanecerá en silencio si envía el CRC incorrecto con su comando (que es un poco estúpido en mi opinión)
Y estoy de acuerdo, su séptimo bit debería ser 0 si su tarjeta no admite doble voltaje (cf 7.1)
Ahora lo tengo funcionando. La razón es que no emití CMD0 antes de enviar CMD1, aunque todavía no entiendo porque A.6.1 no menciona eso. ¡Gracias de todas formas!
@Fluffy Oye, sé que ha pasado un tiempo, pero ¿sabiste por qué la parte ocupada se mantuvo baja? Tengo el mismo problema, no puedo pasar de CMD1 porque el chip siempre dice que está ocupado.
@Pikrass De hecho, ha pasado un tiempo: D El conector bga que estaba usando estaba defectuoso, usé otro con exactamente el mismo cableado y terminó funcionando de inmediato. Un análisis posterior mostró una línea de alimentación mal impresa en la PCB. Por lo que recuerdo, el eMMC bajó su bit de ocupado después de 3 o 4 solicitudes CMD1

Se supone que CMD 1 tiene el código OCR sin el bit ocupado como carga útil de 32 bits. deberías estar enviando

cmd <="01" & "000001" & x"80FF8080" & "0010110" & '1';

según apartado A.6.1 para chips con capacidad menor o igual a 2GB y

cmd <="01" & "000001" & x"C0FF8080" & "1011111" & '1';

para chips de más de 2 GB.

Como nota al margen, si no necesita una operación de alta velocidad, le recomiendo usar una tarjeta SD en modo SPI sobre eMMC porque he pasado por el proceso de implementación de un controlador compatible con HS400 y es bastante doloroso.
Gracias por señalar eso, ¡no vi esa información! La documentación es realmente densa. Lamentablemente no resuelve mi problema, todavía no hay respuesta. Estoy agregando captura de mi analizador lógico, tal vez me estoy perdiendo algo.
@Fluff'n'Stuff Hay un retraso de inicio de ciclo de reloj de 1 milisegundo + 74 antes de que deba enviar cualquier comando. Además, verifique que la línea de comando esté configurada en alta impedancia (Z) después de enviar el comando.
Muchas gracias, fue más o menos una combinación de todas esas cosas, tenía el comando incorrecto, cmd no se abrió correctamente. Ahora recibo una respuesta, aunque no es la correcta; 0x00ff8080. ¡Pero estoy llegando allí!
Una vez más, volviendo a A.6.1, si obtiene 0x00ff8080 como respuesta para su tarjeta de 1 GB, simplemente repita CMD1 hasta que la respuesta sea 0x80FF8080. Para el chip eMMC, esperará 0x40FF8080 como respuesta "Ocupado" y cuando el chip no esté ocupado obtendrá 0xC0FF8080
Sí, seguí eso. Simplemente no estaba obteniendo la respuesta correcta, después de muchos intentos. La razón de esto es que el chip no estaba correctamente alimentado, estoy usando un enchufe chino barato para el chip eMMC sin ningún tipo de documentación, lo he descubierto ahora, 0xC0FF8080 ¡sí! gracias por su ayuda