Memoria Flash SPI con ATMega1284

3

He conectado un IC de memoria flash SST26VF064B de 8Mb a un ATMeag1284 como se muestra en el siguiente diagrama. Mi plan es hablar con SPI.

Tengaencuentaquetodosloscondensadoresenelesquemason100nF.

AlleerelIDdeJEDECnoobtengolosvaloresesperados.PrimeroestablezcolalíneaSSenbaja,luegoenvíoelcomando0x9F,luegoleo3bytes(enviando0xffdatosficticios)y,finalmente,lalíneaSSvuelveasubir.La hoja de datos me dice que la ID debe ser 0xBF 0x26 0x43 para el dispositivo específico Tengo (ver página 24). Sospecho que algo está mal con mi conexión SPI. Sin embargo, la lectura del osciloscopio de las líneas SCK, MOSI y SS se ve como se esperaba. También mi código decodifica correctamente el patrón en la línea MISO como 0x7c 0x20 0x6f . Puede encontrar las lecturas del osciloscopio a continuación.

Además, intenté leer el estado y la configuración con los comandos 0x05 respectivamente 0x35 . Sin embargo, ambos devuelven solo 0x00 . Según la hoja de datos, al menos el registro de configuración debe contener un 1 en la configuración de fábrica en el 3er bit.

El siguiente código se ejecuta en ATMega1284:

#define F_CPU 8000000UL

#include <avr/io.h>
#include <util/delay.h>

void setSSLow() {
    // Drive SS to low
    PORTB &= ~(1<<PINB4);
}

void setSSHigh() {
    // Set SS to high
    PORTB |= (1<<PINB4);
}

void SPI_MasterInit(void)
{
    // Set SS, MOSI and SCK output, all others input
    DDRB = (1<<PINB4)|(1<<PINB5)|(1<<PINB7);
    setSSHigh();

    // Enable SPI, Master, set clock rate fck/128 
    // Sample on rising edge, output on falling
    SPCR = (1<<SPE)|(1<<MSTR)|(1<<SPR0)|(1<<SPR1)|(0<<CPHA)|(0<<CPOL);
}

char SPI_MasterTransmit(char cData)
{
    // Start transmission 
    SPDR = cData;
    // Wait for transmission complete
    while(!(SPSR & (1<<SPIF))) ;

    char receivedData = SPDR;
    return receivedData;
}

char buffer[3];

int main(void)
{
    SPI_MasterInit();

    // Send 'Read JEDEC ID' command
    setSSLow();
    char status = SPI_MasterTransmit(0x9f);

    // Get data
    for (int i=0; i<3; i++) {
        char data = SPI_MasterTransmit(0xff);
        buffer[i] = data;
    }
    setSSHigh();

    _delay_ms(1000);

    while (1) {
        // Do nothing
    }
}

SCK y SS

SCKyMOSI

SCKyMISO

Ahora estoy en un punto en el que no puedo pensar en otra cosa que hacer para tratar de solucionar este problema. ¡Sería muy útil para cualquier ayuda que pueda proporcionar! Esta es la primera vez que uso SPI y es muy difícil para mí depurar el hardware ya que tengo un fondo de software.

ACTUALIZACIÓN 1

Lo comprobé todo hoy y todo me parece correcto. Sin embargo, todavía obtengo el mismo resultado al leer el ID de JEDEC. Como se menciona en los comentarios a continuación, es una secuencia de bytes que se repite:

7c 20 6f 84 0d f0 81 be 10 37 c2 06 f8 40 df 08 1b e1 03

Como tenía el mismo chip en la carcasa de 16 pines, soldé rápidamente una tabla de ruptura y reemplacé el chip. Sorprendentemente me sale exactamente el mismo comportamiento. Definitivamente creo que hay algo mal en la forma en que lo hago, pero todavía no veo cómo ...

ACTUALIZACIÓN 2

Como ya mencioné en los comentarios, logré que el chip de memoria funcionara con un Arduino. Así que investigué más allá. Cargué el código que usé en el ATMega1284 directamente en el Arduino. Y adivina qué: funcionó fuera de la caja. Así que debe haber algo mal con el ATMega que estoy usando. Además, rápidamente escribí una implementación de software SPI utilizando otros pines y luego los utilizados por el hardware SPI. Y esto también funciona. Intentaré poner en mis manos otro ATMega1284 e intentarlo con ese. Supongo que rompí algo en el ATMega1284 ...

ACTUALIZACIÓN 3

Por accidente, solo logré comunicarme con el SSTV26 utilizando el SPI de hardware en el ATMega1284. Todavía tenía cables conectados a SS, MOSI y SCK que no estaban conectados a ninguna otra cosa. Cuando toco estos cables, la comunicación funciona. Cuando no los toco no funciona. Sospecho que hay algo flotando. No tengo las herramientas a mano en este momento.

    
pregunta Sandro Meier

2 respuestas

1

El problema subyacente no tiene nada que ver con el software o los chips que no funcionan correctamente. Estaba usando cables de cinta de 20 cm para conectar el ATMega1284 a la placa externa que contiene el chip de memoria. Separar los cables y extenderlos un poco solucionó los problemas. Probablemente tuve la interferencia entre las señales. Las mediciones de alcance del post inicial se tomaron muy cerca del ATMega1284, donde el efecto probablemente no fue visible. Para asegurarme de que esto no vuelva a suceder en mi configuración de desarrollo, acorté los cables a unos 4 cm. No he tenido más problemas hasta ahora.

¡Gracias a todos por el tiempo que tomaron para echarle un vistazo! Realmente lo aprecio!

    
respondido por el Sandro Meier
0

Demasiado para un comentario, ¿ha intentado enviar un comando de reinicio?

  

5.2 Restablecer-Habilitar (RSTEN) y Restablecer   (RST)   La operación de reinicio se utiliza como un sistema (software)   reinicio que pone el dispositivo en funcionamiento normal Ready   modo. Esta operación consta de dos comandos:   Restablecer-Habilitar (RSTEN) seguido de Restablecer (RST).   Para restablecer el SST26VF064B / 064BA, las unidades host   CE # bajo, envía el comando Restablecer-Habilitar (66H),   y unidades de CE # alta. A continuación, el host conduce el CE # bajo   de nuevo, envía el comando de reinicio (99H), y las unidades   CE # alto, ver Figura 5-1.

     

La operación de reinicio requiere el comando de reinicio-habilitación   seguido del comando de reinicio. Cualquier orden   que no sea el comando Restablecer después de Restablecer-Habilitar   El comando deshabilitará la función de reinicio.

     

Una vez que los comandos Restablecer-Habilitar y Restablecer son exitosos   Ejecutado, el dispositivo vuelve a su funcionamiento normal.   Lee el modo y luego hace lo siguiente: reinicia el   protocolo al modo SPI, restablece la longitud de ráfaga a 8   Bytes, borra todos los bits, excepto el bit 4 (WPLD) y   bit 5 (SEC), en el registro de estado a sus estados predeterminados,   y borra el bit 1 (IOC) en el registro de configuración a su   estado predeterminado. Un dispositivo reiniciado durante un programa activo   o la operación de borrado anula la operación, que puede   causar que los datos del rango de direcciones de destino se corrompan   o perdido. Dependiendo de la operación previa, el   el tiempo de reinicio puede variar. Recuperación de una operación de escritura   Requiere más tiempo de latencia que la recuperación de otros   operaciones Consulte la Tabla 8-2 en la página 49 para restablecer el tiempo   parámetros

    
respondido por el CrossRoads

Lea otras preguntas en las etiquetas