Problema de la interfaz SPI de la tarjeta SD - La operación de lectura devuelve 0x3F / 0xFF en lugar de 0x7F / 0xFE

2

He escrito un controlador SPI para tarjetas SD (en micropython). No había nada disponible para mi hardware específico (un PyC.io LoPy SoC), así que empecé estudiando una larga lista de controladores, escritos en python y C, y la variedad de enfoques era asombrosa. Muchos tenían códigos inútiles / innecesarios, códigos "erróneos" o códigos que pueden funcionar en algunas tarjetas pero no en otras. No hace falta decir que la variedad de diferentes tarjetas SD y su adhesión a la norma no hacen que esto sea una tarea fácil.

En cualquier caso, de la docena de tarjetas SD (todas microSD) que tengo para probar (varias marcas, velocidades y tamaños), todas excepto dos funcionan perfectamente. Ambas son marcas, velocidades y tamaños diferentes, pero se comportan (mal) exactamente de la misma manera. Ambos se inicializan correctamente, devolviendo todos los datos "meta" esperados, pero cuando se hacen los primeros datos leídos, fallan y fallan constantemente.

En el modo SPI, la lectura de un "sector" se inicia enviando un CMD17 de la manera normal (el mismo código en mi controlador que envía todos los demás comandos), luego leyendo un byte a la vez, esperando un "token" que marca el inicio de los datos (en este caso, el token es 0xFE). Para todas mis tarjetas de trabajo, siempre obtengo 0xFE como segundo byte (el primer byte casi siempre es 0x7F, pero se supone que es irrelevante, la especificación SD solo se preocupa por el primer 0xFE). Pero en las dos tarjetas que fallan, siempre obtengo 0x3F seguido de 0xFF. El código falla, porque nunca se vio 0xFE. Pero lo interesante aquí es que 0x3F / 0xFF es 0x7F / 0xFE desplazado en un bit. Por eso siento que esto es un problema de hardware.

He leído casi todo lo que puedo conseguir en relación con SD sobre SPI. He mirado las señales con un alcance (nada inusual para reportar). Mi circuito está alimentado por un suministro de banco de alta calidad y tiene una capacidad de volumen y desacoplamiento suficiente, y tiene cables muy cortos. También he probado las dos tarjetas que fallan en la ranura para tarjetas SD de mi PC, y funcionan como se esperaba. Sin embargo, el problema que describo es 100% consistente.

¿Entonces la pregunta es qué mirar a continuación? He estado en esto por días, y estoy sin ideas en este momento.

    
pregunta eric

1 respuesta

4

Lo descubrí. El problema tiene que ver con que estas dos tarjetas son sensibles a mi liberación de la línea CS entre la emisión del comando de lectura (CMD17) y el inicio de "sondeo" para el token. Todas las demás tarjetas funcionan bien (y, de hecho, todas las demás implementaciones de controladores SPI SD que puedo encontrar liberan CS entre el comando y la encuesta). Regresé y revisé la documentación de SD SPI, y debo decir que no es muy específico en este punto. En cualquier caso, el controlador modificado no solo funciona en las dos tarjetas que estaban fallando, sino en toda mi pila de tarjetas de prueba.

Para aclarar: mi controlador original (basado en mi interpretación de la especificación SD y mirando otros controladores que pude encontrar) trató a CMD17 como un comando normal: afirmar CS, enviar la secuencia de comandos, leer el byte de respuesta y luego deassert CS. Para CMD17, el siguiente paso sería afirmar CS nuevamente, luego comenzar a buscar el "token de datos". Esto realmente funcionó en la mayoría de mis tarjetas de prueba, pero no en dos de ellas. El cambio trata a CMD17 (así como a otros comandos de lectura y escritura) especialmente, por lo que deja a CS confirmado después de enviar el comando y buscar el "token de datos"; Funciona perfectamente en todas las tarjetas que tengo.

    
respondido por el eric

Lea otras preguntas en las etiquetas