STM32, i2c Daten verarbeiten..

[Daniel S. (sany)]

Moin!

Ich arbeite derzeit an einer Kommunikation zwischen einem STM32F407 
(Master) und 6x STM32F103 (Slave) die über I2C im Interrupt / DMA 
Betrieb und einer RJ45 Verbindung kommunizieren sollen.

Der Master erkennt an den RJ45 Ports wo ein Slave angeschlossen wurde, 
da ein Pin auf 3.3V gezogen wird und somit ein Interrupt für den RJ45 
Port ausgelöst wird.

Da die Slave Platinen alle gleich sind, wird beim einstecken jedem Slave 
eine neue I2C Adresse zugewiesen, funktioniert auch prima.

Nun mache ich mir über die Kommunikation gedanken.

Der Master schickt einen Abragebefehl für die Softwareversion an den 
Slave, der Slave soll den Befehl erkennen und entsprechend mit der 
Softwareversion antworten.

Leider hängt mein Hirn etwas...

Um die Daten auf dem Slave zu empfangen nutze ich folgenden Code:

#define GET_VERSION 0x01
#define GET_VOLTAGE 0x02

uint8_t txData[6];
uint8_t RxData[6];

void HAL_I2C_AddrCallback(I2C_HandleTypeDef *hi2c, uint8_t TransferDirection, uint16_t AddrMatchCode)
{
  if(TransferDirection == I2C_DIRECTION_TRANSMIT)
  {
    HAL_I2C_Slave_Seq_Receive_IT(hi2c, RxData, 6, I2C_FIRST_AND_NEXT_FRAME);
  }
  else
  {
    HAL_I2C_Slave_Seq_Transmit_IT(hi2c, txData, 6, I2C_FIRST_AND_LAST_FRAME);
  }
}

void HAL_I2C_SlaveRxCpltCallback(I2C_HandleTypeDef *hi2c)
{
  rxCount++;
        process_data();
}

void process_data()
{
 switch(RxData[0])
 {
   case GET_VERSION:
     txData[0] = 0x1;
     txData[1] = 0x2;
     txData[2] = 0x3;
   break;
   case GET_VOLTAGE:
      txData[0] = 0x6;
      txData[1] = 0x7;
      txData[2] = 0x8;
      txData[3] = 0x9;
   break;
   default:
    break;
 }
}

So nun habe ich diverse Probleme, mit dem jetzigen Code kommt beim 
Master lediglich 6x 0x0 an.

Ich hatte auch schon die Variante,

void HAL_I2C_SlaveRxCpltCallback(I2C_HandleTypeDef *hi2c)
{
  rxCount++;
        process_data();
        HAL_I2C_Slave_Seq_Transmit_IT(hi2c, txData, 6, I2C_FIRST_AND_LAST_FRAME);
}

Leider empfängt der Master dann null komma garnix, über den Analyzer 
sehe ich eben nur das auf den Slave geschrieben wird, aber kein Read...

Weiß jemand zufällig rat, oder stelle ich mich doof an?

[Steve van de Grens (roehrmond)]

Daniel S. schrieb:
> über den Analyzer sehe ich eben nur das
> auf den Slave geschrieben wird, aber kein Read...

Lass uns auch mal gucken, was du da siehst

[Daniel S. (sany)]

Ouh Sorry, hats nicht angehängt.

Bild 1:
Ist die Variante 1 mit:
Hier Empfängt der Master das vom Slave, schickt aber seltsamer weiße 
noch ein NACK mit hinterher.. ?!

void HAL_I2C_AddrCallback(I2C_HandleTypeDef *hi2c, uint8_t TransferDirection, uint16_t AddrMatchCode)

{

  if(TransferDirection == I2C_DIRECTION_TRANSMIT)

  {

    HAL_I2C_Slave_Seq_Receive_IT(hi2c, RxData, 6, I2C_FIRST_AND_NEXT_FRAME);

  }

  else

  {

    HAL_I2C_Slave_Seq_Transmit_IT(hi2c, txData, 6, I2C_FIRST_AND_LAST_FRAME);

  }

}

Bild 2 ist die Variante 2:

void HAL_I2C_SlaveRxCpltCallback(I2C_HandleTypeDef *hi2c)

{

  rxCount++;

        process_data();

        HAL_I2C_Slave_Seq_Transmit_IT(hi2c, txData, 6, I2C_FIRST_AND_LAST_FRAME);

}

Man sieht, der Master versucht zu lesen, erhält aber nix bei Bild 2... 
und der Mastercode bleibt stehen...

[Ali K. (teddy50)]

Fürs Lesen sendet man normalerweise erstmal die Slave Adresse und danach 
ein Write auf die Registeradresse, danach ein Repeated Start, danach 
folgt direkt ein Read.

[Daniel S. (sany)]

Ali K. schrieb:
> Fürs Lesen sendet man normalerweise erstmal die Slave Adresse und danach
> ein Write auf die Registeradresse, danach ein Repeated Start, danach
> folgt direkt ein Read.

Bitte?

Ich nutze die HAL-Bibliothek, warum sollte das bitte falsch sein?

Der Code für den Master:

uint16_t slaveADDR = 0x18<<1;
uint8_t TxData[6] = {0x2,0x2,0x3,0x4,0x5,0x6};

......

  /* USER CODE BEGIN WHILE */
  while (1)
  {
    /* USER CODE END WHILE */

    /* USER CODE BEGIN 3 */

    HAL_I2C_Master_Transmit(&hi2c2, slaveADDR, TxData, 6,1000);
    uint8_t rxData[6];
    while(HAL_I2C_GetState(&hi2c2) != HAL_I2C_STATE_READY) {}

    HAL_I2C_Master_Receive(&hi2c2, slaveADDR, rxData, 6, 1000);
    HAL_Delay(1000);
  }
  /* USER CODE END 3 */

Es wird zu erst an den Slave geschrieben und dann die Daten vom Slave 
abgeholt, was soll denn bitte da nicht passen?

[Ali K. (teddy50)]

Ich meine,dass es in der HAL eine Funktion, die sich WriteRead o.ä. 
nennt, gibt.
Schau mal bitte, habe es gerade nicht im Kopf.

[Daniel S. (sany)]

Ali K. schrieb:
> Ich meine,dass es in der HAL eine Funktion, die sich WriteRead o.ä.
> nennt, gibt.
> Schau mal bitte, habe es gerade nicht im Kopf.

Achso, du meinst die HAL_I2C_Mem_Write / HAL_I2C_Mem_Read funktion.
Möchte aber beim Polling bleiben..

[Steve van de Grens (roehrmond)]

Daniel S. schrieb:
> schickt aber seltsamer weiße noch ein NACK mit hinterher.. ?

Ein Nack wird nicht aktiv gesendet. Ein Nack kommt beim 9. Takt 
zustande, wenn der Empfänger das Byte nicht mit Ack bestätigt.

Das Nack hat den passiven High Pegel des Pull-Up Widerstandes.

[Ali K. (teddy50)]

Daniel S. schrieb:
> Ali K. schrieb:
>> Ich meine,dass es in der HAL eine Funktion, die sich WriteRead o.ä.
>> nennt, gibt.
>> Schau mal bitte, habe es gerade nicht im Kopf.
>
> Achso, du meinst die HAL_I2C_Mem_Write / HAL_I2C_Mem_Read funktion.
> Möchte aber beim Polling bleiben..

Memread ist Polling.

[Harry L. (mysth)]

Daniel S. schrieb:
> die über I2C im Interrupt / DMA
> Betrieb und einer RJ45 Verbindung kommunizieren sollen.

Daniel S. schrieb:
> Möchte aber beim Polling bleiben..

Passt nicht zusammen...merkste selber oder?

[Steve van de Grens (roehrmond)]

Mit der HAL kenne ich  ich  nicht aus, aber I²C habe ich öfters benutzt 
und debuggt.

Dein Bild von Variante 1 zeigt, dass der Master nach dem Read 0x18 
Kommando 6 Bytes liest. Danach beendet er die Übertragung mit NACK und 
STOP. Soweit alles gut.

In der zweiten Variante bestätigt der Slave das Read 0x18 Kommando 
ebenfalls ordentlich mit ACK. Doch danach hält jemand die Taktleitung 
auf LOW, gibt des Bus nicht mehr frei.  Die Spannende Frage ist, wer den 
Bus blockiert: Master oder Slave?

Trenne den Master oder den Slave vom Bus, der Pull-Up Widersdtand soll 
aber bleiben. Wenn der SCL Pegel dabei auf High wechselt, dann hat der 
abgetrennte Busteilnehmer den Bus blockiert. Ansonsten war es der 
andere.

Für eine etwas schnellere Analyse von Blockaden kann die angehängte 
Schaltung als Bus-Ersatz hilfreich sein. Wenn du magst, kannst du sie 2x 
aufbauen so dass du auch an SDA so eine Anzeige hast. Die flackernde LED 
signalisiert Aktivität auf dem Bus. Eine dauerhaft leuchtende 
signalisiert eine Blockierung. Damit kannst du das Programm Zeile für 
Zeile durch steppen und siehst sofort, ab wo der Bus hängt.

Im blockierten Zustand sagt dir der Spannungsabfall an den 47Ω 
Widerständen der SCL Leitung, welche Seite der Bösewicht ist. Auf der 
Seite wo Spannung am Widerstand abfällt ist die Blockade.

Was du auch tun kannst:

Prüfe im Debugger, wo deine Code-Ausführung hängen bleibt. Ich vermute 
in der Zeile

> while(HAL_I2C_GetState(&hi2c2) != HAL_I2C_STATE_READY) {}

Schaue im Quelltext nach, was da genau abgefragt wird und vergleiche das 
mit der Doku im Datenblatt.