E2PROM Atmel AT24C512 - Was ist da anders?

[Christian J. (Gast)]

Hallo,

ich schreib grad die Routinen für ein E2PROM bzw 2 Stück als Bank aber 
mein ACK Polling funzt nicht, was ich mühsam aufgetüfelt habe und was 
bei anderen funktionierte.

Das sind Atmel E2PROMS und normalerweise polle ich nach einem 
Schreibzyklus solange mit Write Zugriffen, bis der Stein mit "ACK" 
antwortet. Dann ist der Zyklus beendet. Es heisst ja auch "Acknowledge 
Polling".

Nur bei dem Teil läuft die Routine in den Timeout :-( Wie ist denn das 
gemeint, was da steht? Auf dem Bus tut sich nichts wenn ich das Polling 
laufen lasse.

Ich polle auf das Event 6 beim STM32F103.

Ersetze ich das Polling durch DelayMs(5) ist alles ok, der Wert steht 
drin, wird auch ausgelesen aber das ist es ja nicht, Ziel ist ja 
maximaler Durchsatz.


Gruss,
Christian

[Jim M. (turboj)]

Christian J. schrieb:
> Auf dem Bus tut sich nichts wenn ich das Polling
> laufen lasse.

Dann ist da was kaputt: Da sollte immer die Adresse mit NACK kommen.

[Christian J. (Gast)]

So etwa? Bei einem PROM von Microchip 24Lc1025 ist da nämlich anders 
beschrieben in dem Manual. Allerdings haben die auch "Bank Bits", nur 2 
Adressleitungen usw.

Hier mal meine Polling Routine, die bei denen von MC funktionierte. Die 
Schleife rödelt solange bis das E2PROM sich bequemt mit einem ACK zu 
antworten, d.h. der interne Zyklus ist beendet. So war es bisher immer.

Nur was meinen die mit "EEPROM will respond with a 0". Das Teil kann ja 
nur eine Null senden, wenn der Master weiter clocked. Und das ist bei 
einer Statemachine wie im Cortex nicht ganz trivial, die hält sich stur 
an den I2C Stndard.

Zum Vergleich mal das Datenblatt eines Microchip Steins gleicher Größe, 
512 kBit.

// ---------------------------------------------------------------
// Warte bis Schreibzyklus beendet ist (ACK Polling)
// ---------------------------------------------------------------
static uint8_t e2p_WaitForWriteReady() {

    // Warte bis Byte weggeschrieben wurde (Slave sendet solange kein ACK)
    uint32_t timeout = I2C_TIMEOUT_MAX;
    do{
        if (--timeout == 0)
            return ERROR;
        /* Erzeuge Schreibzugriff */
        I2C_GenerateSTART(I2C1, ENABLE);
        while(!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_MODE_SELECT));
        /* Sende die Write Adresse */
        I2C_Send7bitAddress(I2C1, E1_WR_ADR, I2C_Direction_Transmitter);
    } while(I2C_WaitForEvent(I2C_EVENT_MASTER_TRANSMITTER_MODE_SELECTED) != SUCCESS);

    // Sequenz abschliessen
    I2C_GenerateSTOP(I2C1, ENABLE);

    return SUCCESS;
}

[Christian J. (Gast)]

Ok,  es klappt .... zumindest die Hardware. Aber meine Auswertung nicht. 
Bin aber zu müde das heute noch zu ergründen. Die I2C Hardware des STM32 
ist ein Brief mit vielen Siegeln bzw ein tiefes Tal der Tränen :-(

[Christian J. (Gast)]

Ich verstehe es nicht !

Was kann daran noch falsch sein? Auf dem LA sehe ich eindeutig, dass das 
EEPROM nach einer Weile von NAK auf ACK wechselt aber die letzte 
Schleife wird einfach nicht verlassen, obwohl sie das müsste.  Es ist 
nicht möglich die Busy Abfrage vor einem Schreibzugriff zu machen, da 
die I2C Statemachine des STM32F103 klare Vorgaben erwartet, was sie 
senden soll und was darauf zurück kommt. Die Events werden nur 
ausgelöst, wenn die erwartete Antwort kommt. Wenn ein ACK erwartet wurde 
aber ein NAK kommt wird das Event einfach nicht ausgelöst.

Ist da schonmal jemand in die Tiefen dieses I2C Interfaces eingestiegen?

Menno...

/* Schreibt ein Byte in eine einzelne Adresse */
uint8_t EE_WriteByte(uint16_t adr, uint8_t data)
{
    uint8_t lower_addr, upper_addr;

    lower_addr = (uint8_t)((0x00FF) & adr);
    adr = adr>>8;
    upper_addr = (uint8_t)((0x00FF) & adr);

    // Wait until I2C1 is not busy anymore
    //while (I2C_GetFlagStatus(I2C1, I2C_FLAG_BUSY));

    // ACK ein
    I2C_AcknowledgeConfig(I2C1, ENABLE);

    /* Erzeuge START Bedingung */
    I2C_GenerateSTART(I2C1, ENABLE);
    if (I2C_WaitForEvent(I2C_EVENT_MASTER_MODE_SELECT) != SUCCESS)
        return ERROR;

    // Adressiere das E2PROM
    I2C_Send7bitAddress(I2C1, E1_WR_ADR, I2C_Direction_Transmitter);
    if (I2C_WaitForEvent(I2C_EVENT_MASTER_TRANSMITTER_MODE_SELECTED) != SUCCESS)
        return ERROR;

    // Adresse als 2 x 8 Bit senden
    I2C_SendData(I2C1,upper_addr);
    if (I2C_WaitForEvent(I2C_EVENT_MASTER_BYTE_TRANSMITTED) != SUCCESS)
        return ERROR;

    I2C_SendData(I2C1, lower_addr);
    if (I2C_WaitForEvent(I2C_EVENT_MASTER_BYTE_TRANSMITTED) != SUCCESS)
        return ERROR;

    // Sende Datum
    I2C_SendData(I2C1, data);
    while (I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_BYTE_TRANSMITTED)!= SUCCESS);

    // Sende I2C3 STOP Condition
    I2C_GenerateSTOP(I2C1, ENABLE);
    while (I2C_GetFlagStatus(I2C1, I2C_FLAG_STOPF));

    /* Warte bis Schreibzyklus beendet wurde */
    do{
        /* Erzeuge Schreibzugriff */
        I2C_GenerateSTART(I2C1, ENABLE);
        while(!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_MODE_SELECT));
        /* Sende die Write Adresse */
        I2C_Send7bitAddress(I2C1, E1_WR_ADR, I2C_Direction_Transmitter);
    } while(I2C_CheckEvent(I2C1,I2C_EVENT_MASTER_TRANSMITTER_MODE_SELECTED) != SUCCESS);

    // Sequenz abschliessen
    I2C_GenerateSTOP(I2C1, ENABLE);


    return SUCCESS;

}

[Peter D. (peda)]

Beitrag "Re: Suche E2PROM Manager für STM32F10x"

[Christian J. (Gast)]

Ich habs am Laufen!

Es stellt sich aber die Frage, ob man bei EEPROM Funktionen den 
Riesenaufwand treiben sollte allen möglichen Fehler ab zu fangen? Gerade 
bei dem STM32Fxxxx Controllern gibt es unzählige Fehlerflags  usw. Wenn 
das EEPROM nicht reagiert wie gewünscht bleibt die CPU komplett hängen 
in den Schleifen und wird erst durch den WDT wieder rausgerissen.

Ich glaube das ist für Hobbyanwendungen etwas zu viel da jede Form von 
Diagnose zu nutzen, da das den Programmcode ganz schön aufbläht.