problema de sector de lectura de la tarjeta SD

1

Estoy usando FatFS . Después de resolver la tarjeta problema de inicialización Estoy tratando de leer el sector 0 , pero la tarjeta devuelve datos no deseados.

Esta es mi operación de lectura: Veoquelatarjetarespondiócon0x00,loquesignificaqueseleeparaentregardatos.

Porsupuesto,misectorzerothdescargadoconunlectordetarjetasUSBsevecorrectamente:

Este es mi registro de depuración (los números CMD están en hexadecimal):

    388:mmc_disk_initialize: SPI initialized
    366:send_cmd_INTERNAL: call 401 Cmd 00 response 01
    403:mmc_disk_initialize: CMD0 okay
    366:send_cmd_INTERNAL: call 405 Cmd 08 response 01
    406:mmc_disk_initialize: CMD8 okay - this is an SDv2 card
    409:mmc_disk_initialize: CMD8 response 000001AA
    413:mmc_disk_initialize: Waiting for leaving idle state
    366:send_cmd_INTERNAL: call 309 Cmd 37 response 01
    366:send_cmd_INTERNAL: call 415 Cmd 29 response 01
    366:send_cmd_INTERNAL: call 309 Cmd 37 response 01
    366:send_cmd_INTERNAL: call 415 Cmd 29 response 01
    366:send_cmd_INTERNAL: call 309 Cmd 37 response 01
    366:send_cmd_INTERNAL: call 415 Cmd 29 response 01
    366:send_cmd_INTERNAL: call 309 Cmd 37 response 01
    366:send_cmd_INTERNAL: call 415 Cmd 29 response 01
    366:send_cmd_INTERNAL: call 309 Cmd 37 response 01
    366:send_cmd_INTERNAL: call 415 Cmd 29 response 01
    366:send_cmd_INTERNAL: call 309 Cmd 37 response 01
    366:send_cmd_INTERNAL: call 415 Cmd 29 response 00
    419:mmc_disk_initialize: Checking CCS bit in OCR
    366:send_cmd_INTERNAL: call 420 Cmd 3A response 00
    423:mmc_disk_initialize: CMD58 response 80FF8000
    452:mmc_disk_initialize: Init okay
    40:disk_initialize: status = 0
    58:disk_read_INTERNAL: Call from 27
    366:send_cmd_INTERNAL: call 494 Cmd 11 response 00
    60:disk_read_INTERNAL: buf=20001588 sector=0 count=1
    27:test_task1: Read result 0
    28:test_task1: dump len 512
    FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
    FE000000000000000000000000000000
    00000000000000000000000000000000
    00000000000000000000000000000000
    00000000000000000000000000000000
    00000000000000000000000000000000
    00000000000000000000000000000000
    00000000000000000000000000000000
    00000000000000000000000000000000
    00000000000000000000000000000000
    00000000000000000000000000000000
    00000000000000000000000000000000
    00000000000000000000000000000000
    00000000000000000000000000000000
    00000000000000000000000000000000
    00000000000000000000000000000000
    00000000000000000000000000000000
    00000000000000000000000000000000
    00000000000000000000000000000000
    00000000000000000000000000000000
    00000000000000000000000000000000
    00000000000000000000000000000000
    00000000000000000000000000000000
    00000000000000000000000000000000
    00000000000000000000000000000000
    00000000000000000000000000000000
    00000000000000000000000000000000
    00000000000000000000000000000000
    0000000000000000001B3DAFBF000080
    0101008311F4FD3E000000C2EF3A0000
    00000000000000000000000000000000
    00000000000000000000000000000000 
  • Mis datos de depuración son 100% consistentes con el tráfico del analizador lógico.
  • La inicialización es la misma que en el controlador de referencia de FatFS, solo se cambia la capa SPI, por lo que esperaría que la inicialización fallara si algo estuviera mal con la SPI en sí misma
  • el reloj SPI es de alrededor de 150 kHz
  • La tarjeta devuelve la misma basura cada vez, otra tarjeta devuelve otra basura de forma confiable
  • Estoy enviando 2 bytes ficticios con alto CS entre comandos

¿Qué debo marcar / cambiar para que el comando de lectura funcione de manera confiable?

    
pregunta filo

3 respuestas

1

El problema era que estaba empezando a tratar los datos que vienen directamente después de 0x00 de la tarjeta como carga útil del sector. Lo arreglé esperando primero 0x00 después de enviar el comando, y luego esperando 0xFE (que es el inicio del byte de datos). Ahora puedo leer el sistema de archivos y listar archivos.

    
respondido por el filo
1

Lo que lees om el µC es el MBR (Master Boot Record) con la tabla de particiones. ¡Estos datos no se pueden leer en un sistema operativo como Windows sin privilegios de administrador! Los datos del lector de tarjetas USB muestran claramente el primer sector de la "unidad" (partición), que es no sector 0 (cero).

Algunos editores hexadecimales pueden mostrar su MBR si se inician como administradores, pero debe usar el dispositivo físico correcto, que no tiene letra de unidad.

    
respondido por el Turbo J
1

Veamos los vertederos:

  • el volcado hexadecimal de la tarjeta SD muestra la ejecución correcta del comando. Los datos comienzan con el token de datos (FE) y, como dijo TurboJ, parece ser una tabla de particiones, sin embargo, hay algunos artefactos allí (1B3DAFBF0000). Primera información del volumen de MBR:

    80 01 01 00 83 11 F4 FD 3E 00 00 00 C2 EF 3A 00

Partición activa, tipo 83 (partición nativa de Linux), el primer LBA del volumen es 0000003E y el tamaño 003AEFC2 (1,977,582,592 ~ 2 GB de partición).

  • su primer volcado hexadecimal realmente muestra el sector de arranque del sistema de archivos FAT12, que es otra parte del sistema de archivos. Su ID OEM muestra MSWIN4.1 (formateado en Windows 95/98 / ME); El descriptor de medios es 0xF8 (disco duro); los sectores por grupo son 0x40 (64); Número de sectores 0x5545 (11,176,448 bytes en volumen). No es un disquete, no es un disco duro. Lo más probable es que se formateó con alguna aplicación que crea imágenes para dispositivos más antiguos que admiten FAT12 y falsifica la identificación OEM para que ese dispositivo sea legible en Windows / Linux / mobiles.

Conclusión: es difícil llegar a una conclusión. Lea la tarjeta SD completa en su host de Windows / Linux (por ejemplo, usando Image Writer) y búsquelo usando el visor hex / binario. La estructura de la tarjeta puede ser creada por alguna herramienta especial, por lo que su contenido puede ser impredecible. Pero lo que sí puedo decir es que el sector de arranque que proporcionó en el primer volcado, en circunstancias normales, no debería corresponder al volumen del dispositivo que tiene MBR en el segundo volcado.

    
respondido por el Anonymous

Lea otras preguntas en las etiquetas