Problemas de comunicación de la tarjeta SPI / SD

Navega tus respuestas
4

Estoy trabajando con un PIC18F67K22 y estoy viendo algunas cosas extrañas en el flujo de datos SPI. Estoy tratando de interactuar con una partición FAT32 usando FatFs y un archivo diskio.c creado a la medida. Soy capaz de reconocer la partición FAT32, pero cuando intento crear un archivo, la operación disk_read repentinamente produce errores extraños.

He adjuntado una captura de pantalla de la lógica entre el PIC18 y la tarjeta SD para mostrar los datos inusuales.

Enlacapturadepantalla,puedeverqueestoyenviandoCMD17(READ_SINGLE_BLOCK)juntoconunadirecciónde4bytesde0x00007D10yunasumadecomprobaciónCRC7paraesecomando.

Larespuestadelcomandoquereciboes0xC1,seguidade0x3F,ningunadelascualestienesentido.Deacuerdoconlasección Cómo usar MMC / SDC en el sitio web de FatFs, el bit más significativo de la respuesta del comando debería siempre hay un 0, pero 0xC1 tiene el bit más significativo establecido en 1. Además, ¿por qué viene el 0x3F después? Eso debería ser 0xFF.

E incluso si asumiera que había un pequeño cambio aquí y el valor real debería ser 0xC13F > > 6 (0x04), eso sería un comando ilegal. ¿Qué es ilegal acerca de CMD17 con esa dirección? ¿La dirección de datos de 0x00007D10 no es válida? La partición debe abarcar todo el medio, excepto el MBR y el registro de inicio.

Editar:

Aquí están los sectores devueltos durante la inicialización, con algunas anotaciones en los datos:

Edit 2:

He descubierto que esto solo sucede si llamo a f_mount mucho antes de f_open. Estoy haciendo un f_mount al insertar la tarjeta SD para verificar que la tarjeta es una partición FAT16 / FAT32 adecuada, y luego solo llamo a f_open cuando el usuario comienza a registrar datos. Si llamo a f_mount y f_open en rápida sucesión (o llamo a f_mount con montaje retrasado), entonces la llamada funciona bien y el comando devuelve 0x00 y luego 512 bytes de datos.

    
pregunta kingcoyote

1 respuesta

2

Ha pasado un año desde que se hizo la pregunta, pero decidí agregarle porque tenía problemas similares al insertar el controlador de la tarjeta SD en FPGA. Estoy de acuerdo con los comentaristas con su pregunta de que necesita proporcionar información sobre lo que estaba sucediendo antes del ciclo SPI fallido y lo que sucede después.

En general, si bien hay una especificación de SD para las tarjetas SD, está un poco desconcertado y no hace que dedique una hora a comprender lo que está mal con mi diseño.

Entonces, comencemos ...

  • Inicialización: hay un requisito previo para tener ciclos de reloj de repuesto con CS desactivado para que la tarjeta se inicialice y entienda que hay un host ahí fuera. También obtendrá una idea de qué tipo de SPI se utiliza.
  • Inicio del ciclo de comando: necesitará ciclos de reloj de repuesto antes de que active CS low para iniciar el comando, e idealmente varios ciclos de reloj después de que active CS low y comience a poner el comando en la línea MOSI. Varios aquí significa n * 8. Esos ciclos de repuesto son necesarios para garantizar que la tarjeta se recupere del ciclo de E / S anterior si hubo un problema en él (por ejemplo, su aplicación no transfirió datos / estado completos, y la tarjeta aún espera que el host lea / envíe estos datos o estado). La poca actividad con CS high convencerá a la tarjeta de que se debe cancelar la operación anterior.

Cuando hice estos dos anteriores correctamente, ya no obtuve códigos de respuesta inválidos de la tarjeta SD. Existen algunas otras peculiaridades en el manejo de tarjetas SD a través de SPI, pero deben tratarse cuando sea necesario, ya que el ciclo de comando en sí, entonces la fase de respuesta y de datos están relativamente bien explicadas en la especificación, y es probable que no tenga problemas para implementarla. p>     

respondido por el Anonymous

Lea otras preguntas en las etiquetas

Pregunta de diseño con respecto a los cables de alta corriente que se encuentran debajo de la PCB Sobretensión DS2480B de 1 cable y protección ESD