I2C auf STM32F103

[Richard M. (Gast)]

Hallo zusammen,

ich habe hier ein Problem mit dem I2C und bekomm diesen einfach nicht 
zum laufen. Als Hardware habe ich hier einen STM32F103ZE mit einem 
Segger Ultra + und einem Saleae Logic Analyser zum auslesen der SCL und 
SDA Pins.

Der folgende Code ist unter embOS initialisiert:

void ConfigureI2CGPIO(void) 
{
  GPIO_InitTypeDef GPIO_InitStructure;
        I2C_InitTypeDef   I2C_InitStructure;

  RCC_AHBPeriphClockCmd(RCC_APB2Periph_GPIOB, ENABLE);
  RCC_APB1PeriphClockCmd(RCC_APB1Periph_I2C1, ENABLE);
        SET_BIT(RCC->APB2ENR, RCC_APB2ENR_AFIOEN);

        GPIO_PinRemapConfig(AFIO_MAPR_I2C1_REMAP, ENABLE);

        GPIO_InitStructure.GPIO_Pin =  (GPIO_Pin_8) | (GPIO_Pin_9);     //SCL (PB6),SDA (PB7): Alternate Function, Open Drain
        GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
        GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF_OD; // Open Drain, I2C bus pulled high externally  
        GPIO_Init(GPIOB, &GPIO_InitStructure);
                
        I2C_Cmd(I2C1, DISABLE);          
        
        I2C_InitStructure.I2C_ClockSpeed=100000;
        I2C_InitStructure.I2C_Mode=I2C_Mode_I2C;
        I2C_InitStructure.I2C_DutyCycle=I2C_DutyCycle_2;
        I2C_InitStructure.I2C_OwnAddress1=0;
        I2C_InitStructure.I2C_Ack=I2C_Ack_Enable;
        I2C_InitStructure.I2C_AcknowledgedAddress=I2C_AcknowledgedAddress_7bit; 
        I2C_Init(I2C1, &I2C_InitStructure);

        I2C_Cmd(I2C1, ENABLE);
  //GPIO_PinRemapConfig(AFIO_MAPR_I2C1_REMAP, ENABLE);

        GPIOB->BSRR = I2C_SCL_PIN | I2C_SDA_PIN;

  GPIO_InitStructure.GPIO_Pin = I2C_SCL_PIN;
  GPIO_InitStructure.GPIO_Mode = GPIO_Mode_IN_FLOATING;
  GPIO_Init(I2C_SCL_GPIO_PORT, &GPIO_InitStructure);

  GPIO_InitStructure.GPIO_Pin = I2C_SDA_PIN;
  GPIO_Init(I2C_SDA_GPIO_PORT, &GPIO_InitStructure);

  RCC_APB1PeriphClockCmd(RCC_APB1Periph_I2C1, ENABLE);

  RCC_APB2PeriphClockCmd(I2C_SCL_GPIO_CLK | I2C_SDA_GPIO_CLK | I2C_SMBUSALERT_GPIO_CLK, ENABLE);

  GPIO_InitStructure.GPIO_Pin = I2C_SCL_PIN;
  GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
  GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF_OD;
  GPIO_Init(I2C_SCL_GPIO_PORT, &GPIO_InitStructure);

  GPIO_InitStructure.GPIO_Pin = I2C_SDA_PIN;
  GPIO_Init(I2C_SDA_GPIO_PORT, &GPIO_InitStructure);
}

void I2C_Eeprom_Write(int num, uint8_t *ptxbuf) 
{
        ConvertMessage(num, ptxbuf);

  I2C_GenerateSTART(I2C1, ENABLE);

  while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_MODE_SELECT));
  
  I2C_Send7bitAddress(I2C1, I2C_EEPROM_ADDRESS >> 1, I2C_Direction_Transmitter);

  while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_TRANSMITTER_MODE_SELECTED));

  I2C_SendData(I2C1, *ptxbuf);

  while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_BYTE_TRANSMITTED));

  I2C_SendData(I2C1, *(++ptxbuf));
  while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_BYTE_TRANSMITTED));
      
  I2C_GenerateSTOP(I2C1, ENABLE);
}

Das Problem ist, dass mir der Code beim senden an den EEPROM bei

  while (!I2C_CheckEvent(I2C1, I2C_EVENT_MASTER_MODE_SELECT));

hängen bleibt und gar nichts mehr geht... Mit dem Logic Analyser kann 
ich weder an SCL noch an SDA was erkennen... Die Pins bleiben einfach 
auf high. Pull-Ups sind vorhanden.

Ich weiß mir nicht mehr zu helfen woran es liegen könnte. Habe 
zahlreiche Versuche gestartet aber ich komm nicht mehr weiter.

Kann mir hier vielleicht einer einen Rat geben woran es liegen könnte?

Als Anmerkung:

Er geht in der I2C_CheckEvent in den ERROR-Fall... Also muss ein Bit 
nicht gesetzt worden sein, also nehm ich an.

ErrorStatus I2C_CheckEvent(I2C_TypeDef* I2Cx, uint32_t I2C_EVENT)
{
  uint32_t lastevent = 0;
  uint32_t flag1 = 0, flag2 = 0;
  ErrorStatus status = ERROR;

  /* Check the parameters */
  assert_param(IS_I2C_ALL_PERIPH(I2Cx));
  assert_param(IS_I2C_EVENT(I2C_EVENT));

  /* Read the I2Cx status register */
  flag1 = I2Cx->SR1;
  flag2 = I2Cx->SR2;
  flag2 = flag2 << 16;

  /* Get the last event value from I2C status register */
  lastevent = (flag1 | flag2) & FLAG_Mask;

  /* Check whether the last event contains the I2C_EVENT */
  if ((lastevent & I2C_EVENT) == I2C_EVENT)
  {
    /* SUCCESS: last event is equal to I2C_EVENT */
    status = SUCCESS;
  }
  else
  {
    /* ERROR: last event is different from I2C_EVENT */
    status = ERROR;
  }
  /* Return status */
  return status;
}

Ich danke schonmal,

liebe Grüße
Richard

[Milbe (Gast)]

Sendet "I2C_GenerateSTART(I2C1, ENABLE);" das Startbit? Was ist als 
Slave angeschlossen?

[STM Apprentice (Gast)]

Ich schweife vom Thema ab, aber:

Wieder mal, ich liebe meine Soft-I2C-Library!

Läuft ohne Probleme und ich kann mir im Debugger und am
Bus jedes Bit einzeln anschauen, ganz statisch unhektisch
und ohne Logikanalysator-Gefummel.

Aber da die Library so gut funktioniert musste ich schon
lange nicht mehr den Debugger dafür bemühen.

[Richard M. (Gast)]

Milbe schrieb:
> Sendet "I2C_GenerateSTART(I2C1, ENABLE);" das Startbit? Was ist als
> Slave angeschlossen?

Wie man sieht ein EEPROM... Das Startbit wird auch nicht gesendet. Wenn 
ich die Messung starte ändert sich im Verlauf von 20 Sekunden nichts.

STM Apprentice schrieb:
> Wieder mal, ich liebe meine Soft-I2C-Library!

Ist die zu haben? Oder haben Sie eine Idee woran das liegen könnte? 
Könnte wirklich Hilfe gebrauchen.

[Dr. Sommer (Gast)]

Richard M. schrieb:
> GPIO_PinRemapConfig(AFIO_MAPR_I2C1_REMAP, ENABLE);

Geprüft ob das stimmt? Welche Pins benutzt du? Die Pins sind ständig 
High und es tut sich gar nichts? Was passiert wenn du das EEPROM trennst 
und die Leitungen per LA anschaust?

[Richard M. (Gast)]

Dr. Sommer schrieb:
> Geprüft ob das stimmt? Welche Pins benutzt du?

Pin 8 und 9, Das ist das Remapping des STM32F103ZE. Standard wären diese 
Pin 6 und 7.

Dr. Sommer schrieb:
> Die Pins sind ständig High und es tut sich gar nichts? Was passiert wenn du das 
EEPROM trennst und die Leitungen per LA anschaust?

Ebenfalls nichts, rein gar nichts. Beide Kanäle bleiben durchgehend auf 
HIGH

[Dr. Sommer (Gast)]

Richard M. schrieb:
> RCC_APB1PeriphClockCmd(RCC_APB1Periph_I2C1, ENABLE);

Warum ist das doppelt? Warum initialisierst du die Pins 3x?

[Richard M. (Gast)]

Dr. Sommer schrieb:
> Warum ist das doppelt? Warum initialisierst du die Pins 3x?

Das kommt aus einer bestehenden Datei eines anderen RTOS.

Habe ich so übernommen, ändert ja nix an der eigentlichen init, wird 
eben nur wieder überschrieben oder nicht?

[W.S. (Gast)]

Richard M. schrieb:
> Ist die zu haben?

Ist die denn wirklich so schwer selbst zu schreiben? Es sind doch bloß 2 
Leitungen. Ich selber verwende auch einen Software-Lowlevel-Treiber 
recht oft und ich hab den hier auch schon mal gepostet. Ich häng dir mal 
sowas dran, der war (wenn ich mich recht erinnere) damals für nen 
Kinetis. ist schon ne Weile her.

Und wenn du das Umschreiben auf STM32 nicht aus eigener Kraft zuwege 
bringst, dann werde Briefmarkensammler oder Tanzlehrer.

W.S.

[Richard M. (Gast)]

W.S. schrieb:
> Und wenn du das Umschreiben auf STM32 nicht aus eigener Kraft zuwege
> bringst, dann werde Briefmarkensammler oder Tanzlehrer.
>
> W.S.

Klar, bist ja auf die Welt gekommen und warst allwissend. Bleib mal am 
Boden

[Dr. Sommer (Gast)]

Richard M. schrieb:
> Habe ich so übernommen, ändert ja nix an der eigentlichen init, wird
> eben nur wieder überschrieben oder nicht?

Weiß nicht, es sieht irgendwie komisch aus. Und da es ja nicht 
funktioniert...

[Richard M. (Gast)]

Dr. Sommer schrieb:
> Weiß nicht, es sieht irgendwie komisch aus. Und da es ja nicht
> funktioniert...

Hab jetzt eine init gemacht der GPIOs, änder nichts an dem Fehler dass 
er nicht mal das Startbit generiert. Ich finde den Fehler einfach nicht.

[Dr. Sommer (Gast)]

Richard M. schrieb:
> Hab jetzt eine init gemacht der GPIOs, änder nichts an dem Fehler dass
> er nicht mal das Startbit generiert. Ich finde den Fehler einfach nicht.

Zeig den neuen Code, die Definition der Makros I2C_SCL_PIN etc. 
Irgendwas muss an der Pin Konfiguration falsch sein. Wird die vielleicht 
irgendwo von einem anderen Programmteil überschrieben?

[Richard M. (Gast)]

/* STM32 Include files ******************************************************/

#include <stm32f10x_i2c.h>

/* Macro defintions  ********************************************************/

#define I2C_SCL_PIN                     GPIO_Pin_6
#define I2C_SCL_GPIO_PORT               GPIOB
#define I2C_SDA_PIN                     GPIO_Pin_7
#define I2C_SDA_GPIO_PORT               GPIOB

#define I2C_SCL_GPIO_CLK                RCC_APB2Periph_GPIOB
#define I2C_SDA_GPIO_CLK                RCC_APB2Periph_GPIOB
#define I2C_SMBUSALERT_GPIO_CLK         RCC_APB2Periph_GPIOB

/* EEPROM */
#define I2C_EEPROM_ADDRESS              0xA8

/* General information ******************************************************/

/* Types ********************************************************************/

/* Local Prototypes *********************************************************/

void ConfigureI2CGPIO(void);

/* Global variables *********************************************************/

/* Functions ****************************************************************/

void ConfigureI2CGPIO(void) 
{
  GPIO_InitTypeDef GPIO_InitStructure;
        I2C_InitTypeDef   I2C_InitStructure;

  RCC_AHBPeriphClockCmd(RCC_APB2Periph_GPIOB, ENABLE);
  RCC_APB1PeriphClockCmd(RCC_APB1Periph_I2C1, ENABLE);
        SET_BIT(RCC->APB2ENR, RCC_APB2ENR_AFIOEN);

        //TODO: APB1 Reset Register

        GPIO_PinRemapConfig(AFIO_MAPR_I2C1_REMAP, ENABLE);

        GPIO_InitStructure.GPIO_Pin =  (GPIO_Pin_6) | (GPIO_Pin_7);     //SCL (PB6),SDA (PB7): Alternate Function, Open Drain
        GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
        GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF_OD; // Open Drain, I2C bus pulled high externally  
        GPIO_Init(GPIOB, &GPIO_InitStructure);
                
        I2C_Cmd(I2C1, DISABLE);          
        
        I2C_InitStructure.I2C_ClockSpeed=100000;
        I2C_InitStructure.I2C_Mode=I2C_Mode_I2C;
        I2C_InitStructure.I2C_DutyCycle=I2C_DutyCycle_2;
        I2C_InitStructure.I2C_OwnAddress1=0;
        I2C_InitStructure.I2C_Ack=I2C_Ack_Enable;
        I2C_InitStructure.I2C_AcknowledgedAddress=I2C_AcknowledgedAddress_7bit; 
        I2C_Init(I2C1, &I2C_InitStructure);

        I2C_Cmd(I2C1, ENABLE);

        GPIOB->BSRR = I2C_SCL_PIN | I2C_SDA_PIN;

  GPIO_InitStructure.GPIO_Pin = I2C_SCL_PIN;
  GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
  GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF_OD;
  GPIO_Init(I2C_SCL_GPIO_PORT, &GPIO_InitStructure);

  GPIO_InitStructure.GPIO_Pin = I2C_SDA_PIN;
  GPIO_Init(I2C_SDA_GPIO_PORT, &GPIO_InitStructure);
}

Hier mit defines, die werden nirgends sonst definiert.

[Richard M. (Gast)]

Pin 6 und 7 wurden wieder auf 8 und 9 geändert... Hab grad auf einem 
EVAL probiert... Funktionierte auch nicht

[Stefan F. (Gast)]

Vielleicht kommst du ohne diese komische Abstraktions-Library besser 
zurecht. Hier ein kommentiertes Beispiel:

http://stefanfrings.de/stm32/index.html#i2c

[Richard M. (Gast)]

Stefanus F. schrieb:
> Vielleicht kommst du ohne diese komische Abstraktions-Library besser
> zurecht. Hier ein kommentiertes Beispiel:
>
> http://stefanfrings.de/stm32/index.html#i2c

Hab ich auch schon probiert. Hat leider auch nicht funktioniert.. Ich 
verzweifle langsam daran....

[Dr. Sommer (Gast)]

Richard M. schrieb:
> RCC_AHBPeriphClockCmd(RCC_APB2Periph_GPIOB, ENABLE);

Ist verkehrt... einmal AHB und einmal APB2. Die GPIO-Initialisierung ist 
immer noch doppelt. Steppe den Code im Debugger durch und schaue ob in 
den Registern die gewünschten Dinge landen.

[Stefan F. (Gast)]

Was hat leider auch nicht funktioniert?
Welchen Pegel haben die beiden Leitungen SDA und SCL im Ruhezustand 
(nach der Initialisierung)?
Welchen Pegel haben sie nachdem der Fehler begonnen hat?
Welches Signal misst du mit deinem Logic Analyzer?
Bist du sicher, dass der Logic Analyzer funktioniert und dass du ihn 
richtig bedienst?
Hast du die GND Leitung vom EEprom mit dem STM32 verbunden?
Hast du anstelle des EEproms mal einen anderen Chip probiert? Der 
PCF8574 ist für erste Versuche immer gut.
Hast du mal versucht, einfach gar keinen Slave anzuschliessen, um nur 
die Ausgangs-Signale des STM32 zu prüfen? Zumindest die Adresse (also 
das erste Byte) müsste zu sehen sein.
Zeige mal deinen Schaltplan.
Zeige mal dein Programm, das auf meinem Code basiert.

Probiere das alles aus, beantworte die Fragen und dann sehen wir weiter.

[Dr. Sommer (Gast)]

PS: absolut sicher dass kein Verdrahtungs-Fehler vorliegt? Kannst du die 
Pins normal als GPIO konfigurieren und auf Low schalten?

[Richard M. (Gast)]

Stefanus F. schrieb:
> Was hat leider auch nicht funktioniert?
> Welchen Pegel haben die beiden Leitungen SDA und SCL im Ruhezustand
> (nach der Initialisierung)?
> Welchen Pegel haben sie nachdem der Fehler begonnen hat?
> ...

Ich werd dir da morgen eine ausreichende Diagnose geben und deinen Code 
nochmals verwenden. Auch bei entferntem EEPROM bleibt der Fehler 
bestehen. Die Signale sind stets auf HIGH

[Stefan F. (Gast)]

Richard M. schrieb:
> Stefanus F. schrieb:
>> Was hat leider auch nicht funktioniert?
>> Welchen Pegel haben die beiden Leitungen SDA und SCL im Ruhezustand
>> (nach der Initialisierung)?
>> Welchen Pegel haben sie nachdem der Fehler begonnen hat?
>> ...
>
> Ich werd dir da morgen eine ausreichende Diagnose geben und deinen Code
> nochmals verwenden. Auch bei entferntem EEPROM bleibt der Fehler
> bestehen. Die Signale sind stets auf HIGH

Das mein Beispielprogramm erprobt ist und funktioniert sollte das (ohne 
EEprom) zumindest die Slave Adresse ausgeben. Tut es das nicht, ist 
möglicherweise dein µC defekt.

[Richard M. (Gast)]

Dr. Sommer schrieb:
> PS: absolut sicher dass kein Verdrahtungs-Fehler vorliegt? Kannst
> du die Pins normal als GPIO konfigurieren und auf Low schalten?

Verdrahtungsfehler liegt keiner vor, alles schon überprüft. Ich werd 
morgen mal alles nochmal durchtesten. Die Pins als einfache DO verwenden 
und dann Stefanus Init nochmals anwenden. Vll. seh ich den Wald vor 
lauter Bäumen nicht mehr...

[Richard M. (Gast)]

Stefanus F. schrieb:

> Das mein Beispielprogramm erprobt ist und funktioniert sollte das (ohne
> EEprom) zumindest die Slave Adresse ausgeben. Tut es das nicht, ist
> möglicherweise dein µC defekt.

Ich werd das alles nochmal durchprobieren. Ich melde mich morgen 
nochmal. Danke vorab

[Richard M. (Gast)]

Ich habe jetzt die Initialisierung nach Stefanus durchgeführt:

void i2c_init(I2C_TypeDef* registerStruct, bool fastMode, uint32_t apb1_clock)
{
    SET_BIT(RCC->APB2ENR, RCC_APB2ENR_IOPBEN);
    SET_BIT(RCC->APB2ENR, RCC_APB2ENR_AFIOEN);
    
    // Enable clock
    if (registerStruct==I2C1)
    {
        SET_BIT(RCC->APB1ENR, RCC_APB1ENR_I2C1EN);
    }
    else if (registerStruct==I2C2)
    {
        SET_BIT(RCC->APB1ENR, RCC_APB1ENR_I2C2EN);
    }
    
    // Configure timing
    MODIFY_REG(registerStruct->CR2, I2C_CR2_FREQ, apb1_clock/1000000); 
    if (fastMode)
    {
        MODIFY_REG(registerStruct->CCR, I2C_CCR_CCR, apb1_clock/800000);
        MODIFY_REG(registerStruct->TRISE, I2C_TRISE_TRISE, apb1_clock/4000000+1);
    }
    else
    {
        MODIFY_REG(registerStruct->CCR, I2C_CCR_CCR, apb1_clock/200000);
        MODIFY_REG(registerStruct->TRISE, I2C_TRISE_TRISE, apb1_clock/1000000+1);
    }
    
    // Enable the peripheral
    SET_BIT(registerStruct->CR1, I2C_CR1_PE);
}

unsigned int i2c_communicate(I2C_TypeDef* registerStruct, uint8_t slave_addr, 
    void* send_buffer, unsigned int send_size, void* receive_buffer, unsigned int receive_size)
{
    unsigned int receive_count=0;

    // shift the 7bit address to the right position
    slave_addr=slave_addr<<1;

    // Send data
    if (send_size>0)
    {
        // Send START and slave address
        SET_BIT(registerStruct->CR1, I2C_CR1_START);                     // send START condition
        while (!READ_BIT(registerStruct->SR1, I2C_SR1_SB));              // wait until START has been generated
        WRITE_REG(registerStruct->DR,slave_addr);                        // send slave address
        while (!READ_BIT(registerStruct->SR1, I2C_SR1_ADDR))             // wait until address has been sent
        {
            if (READ_BIT(registerStruct->SR1, I2C_SR1_AF))
            {
                // did not receive ACK after address
                goto error;
            }
        }

        READ_REG(registerStruct->SR2);                                   // clear ADDR
        while (send_size>0)
        {
            WRITE_REG(registerStruct->DR,*((uint8_t*)send_buffer));      // send 1 byte from buffer
            while (!READ_BIT(registerStruct->SR1, I2C_SR1_TXE))          // wait until Tx register is empty
            {
                if (READ_BIT(registerStruct->SR1, I2C_SR1_AF))
                {
                    // did not receive ACK after data byte
                    goto error;
                }
            }
            send_buffer++;
            send_size--;
        }
        while (!READ_BIT(registerStruct->SR1, I2C_SR1_BTF))              // wait until last byte transfer has finished
        {
            if (READ_BIT(registerStruct->SR1, I2C_SR1_AF))
            {
                // did not receive ACK after data byte
                goto error;
            }
        }
    }

    CLEAR_BIT(registerStruct->CR1, I2C_CR1_POS);                         // POS=0
    SET_BIT(registerStruct->CR1, I2C_CR1_ACK);                           // acknowledge each byte

    // Receive data
    // The procedure includes workaround as described in AN2824
    if (receive_size>0)
    {
        // Send (RE-)START and slave address
        SET_BIT(registerStruct->CR1, I2C_CR1_START);                      // send START condition
        while (!READ_BIT(registerStruct->SR1, I2C_SR1_SB));               // wait until START has been generated
        WRITE_REG(registerStruct->DR,slave_addr+1);                       // send slave address + read mode
        while (!READ_BIT(registerStruct->SR1, I2C_SR1_ADDR))              // wait until address has been sent
        {
            if (READ_BIT(registerStruct->SR1, I2C_SR1_AF))
            {
                // did not receive ACK after address
                goto error;
            }
        }

        if (receive_size>2)
        {
            READ_REG(registerStruct->SR2);                                // clear ADDR
            while (receive_size>3)
            {
                while (!READ_BIT(registerStruct->SR1, I2C_SR1_RXNE));     // wait until a data byte has been received
                *((uint8_t*)receive_buffer)=READ_REG(registerStruct->DR); // read data
                receive_size--;
                receive_count++;
                receive_buffer++;
            }
            while (!READ_BIT(registerStruct->SR1, I2C_SR1_BTF));          // wait until 2 bytes are received
            CLEAR_BIT(registerStruct->CR1, I2C_CR1_ACK);                  // prepare to send a NACK
            *((uint8_t*)receive_buffer)=READ_REG(registerStruct->DR);     // read the penultimate data byte
            receive_size--;
            receive_count++;
            receive_buffer++;
            __disable_irq();
            {
                SET_BIT(registerStruct->CR1, I2C_CR1_STOP);               // prepare to send a STOP condition
                *((uint8_t*)receive_buffer)=READ_REG(registerStruct->DR); // read the last data byte
                receive_size--;
                receive_count++;
                receive_buffer++;
            }
            __enable_irq();
        }
        else if (receive_size==2)
        {
            SET_BIT(registerStruct->CR1, I2C_CR1_POS);                    // NACK shall be applied to the next byte, not the current byte
            __disable_irq();
            {
                READ_REG(registerStruct->SR2);                            // clear ADDR
                CLEAR_BIT(registerStruct->CR1, I2C_CR1_ACK);              // prepare to send a NACK
            }
            __enable_irq();
            while (!READ_BIT(registerStruct->SR1, I2C_SR1_BTF));          // wait until 2 bytes are received
            __disable_irq();
            {
                SET_BIT(registerStruct->CR1, I2C_CR1_STOP);               // prepare to send a STOP condition
                *((uint8_t*)receive_buffer)=READ_REG(registerStruct->DR); // read the penultimate data byte
                receive_size--;
                receive_count++;
                receive_buffer++;
             }
            __enable_irq();
        }
        else if (receive_size==1)
        {
            CLEAR_BIT(registerStruct->CR1, I2C_CR1_ACK);                  // prepare to send a NACK
            __disable_irq();
            {
                READ_REG(registerStruct->SR2);                            // clear ADDR
                SET_BIT(registerStruct->CR1, I2C_CR1_STOP);               // prepare to send a STOP condition
            }
            __enable_irq();
            while (!READ_BIT(registerStruct->SR1, I2C_SR1_RXNE));         // wait until a data byte has been received
        }

        *((uint8_t*)receive_buffer)=READ_REG(registerStruct->DR);         // read the last data byte
        receive_size--;
        receive_count++;
        receive_buffer++;
        while (READ_BIT(registerStruct->SR1, I2C_CR1_STOP));              // wait until STOP has been generated
    }

    else if (receive_size==0 && send_size>0)
    {
        SET_BIT(registerStruct->CR1, I2C_CR1_STOP);                       // send STOP condition
        while (READ_BIT(registerStruct->CR1, I2C_CR1_STOP));              // wait until STOP has been generated
    }

    return receive_count;

    error:
    SET_BIT(registerStruct->CR1, I2C_CR1_STOP);                           // send STOP condition
    while (READ_BIT(registerStruct->CR1, I2C_CR1_STOP));                  // wait until STOP has been generated
    CLEAR_BIT(registerStruct->CR1, I2C_CR1_PE);                           // restart the I2C interface clear all error flags
    SET_BIT(registerStruct->CR1, I2C_CR1_PE);
    //ITM_SendString("I2C bus error!\n");
    return receive_count;
}

Die Aufrufe der Funktionen ist hier zu erkennen:

        i2c_init(I2C1, false, 72000000)
                                                 
        AFIO->MAPR |= AFIO_MAPR_I2C1_REMAP;

        MODIFY_REG(GPIOB->CRL, GPIO_CRH_CNF8  + GPIO_CRH_MODE8,  GPIO_CRH_CNF8_0 + GPIO_CRH_CNF8_1 + GPIO_CRH_MODE8_1);
        MODIFY_REG(GPIOB->CRL, GPIO_CRH_CNF9  + GPIO_CRH_MODE9,  GPIO_CRH_CNF9_0 + GPIO_CRH_CNF9_1 + GPIO_CRH_MODE9_1);

        uint8_t send_buffer[4]={10,20,30,40};
        uint8_t receive_buffer[9];

        // Communicate with slave address 8: send 4 bytes, then receive 9 bytes
        int received=i2c_communicate(I2C1, 168, send_buffer, 4, receive_buffer, 9);

Remapping durchgeführt. CRL und CRH manipuliert und abgeändert. Leider 
dennoch kein I2C möglich. Bleibt wie bisher in

while (!READ_BIT(registerStruct->SR1, I2C_SR1_SB));              // wait until START has been generated

beim senden der Start Condition hängen...

Das Board ist in Ordnung. Hat vorher damit auch funktioniert. 
Verdrahtungsfehler ausgeschlossen. MCU ist in Ordnung. Die Pins sind als 
normale GPIOs zu benutzen.

[Stefan F. (Gast)]

Richard M. schrieb:
> Die Pins als einfache DO verwenden
> und dann Stefanus Init nochmals anwenden. Vll. seh ich den Wald vor
> lauter Bäumen nicht mehr...

Ich wollte eigentlich, dass du das gesamte Programm erstmal 1:1 (als 
neues separates Projekt) probierst, um einen HW Fehler auszuschließen.

Du hast meinen Fragenkatalog noch nicht beantwortet.

[Richard M. (Gast)]

Stefanus F. schrieb:
> Was hat leider auch nicht funktioniert?

Ihre Init

> Welchen Pegel haben die beiden Leitungen SDA und SCL im Ruhezustand
> (nach der Initialisierung)?

Permanent High

> Welchen Pegel haben sie nachdem der Fehler begonnen hat?

Immernoch High

> Welches Signal misst du mit deinem Logic Analyzer?

High?

> Bist du sicher, dass der Logic Analyzer funktioniert und dass du ihn
> richtig bedienst?

Ja

> Hast du die GND Leitung vom EEprom mit dem STM32 verbunden?

Ja

> Hast du anstelle des EEproms mal einen anderen Chip probiert? Der
> PCF8574 ist für erste Versuche immer gut.

Ja, keinen EEPROM aber einen US

> Hast du mal versucht, einfach gar keinen Slave anzuschliessen, um nur
> die Ausgangs-Signale des STM32 zu prüfen? Zumindest die Adresse (also
> das erste Byte) müsste zu sehen sein.

Ja, selbiges Problem

> Zeige mal deinen Schaltplan.

STM3210E-EVAL Board

> Zeige mal dein Programm, das auf meinem Code basiert.

embOS mit lediglicher Init des I2C.

[Richard M. (Gast)]

> Welches Signal misst du mit deinem Logic Analyzer?

SDA und SCL wenn Sie das meinen.

[Mehmet K. (mkmk)]

STM Apprentice schrieb:
> Wieder mal, ich liebe meine Soft-I2C-Library!

Dieselbe Liebeserklaerung hier aus meiner Ecke.
Nebst dem, dass man nicht behaupten kann, die Errata des STM32F103 
bezüglich I2C sei bescheiden ausgefallen, habe ich nie verstanden, wieso 
man für ein paar Bytes, die man per I2C hin- und herschieben will, nicht 
eine Software-Lösung mit ein paar überschau- und nachvollziehbaren 
Zeilen vorzieht. Eine Lösung, die auf einem STM8 genauso funktioniert, 
wie auf einem STM32. Oder einem EFM8. Oder was auch immer.

Okay, jetzt wird Dr. Sommer kommen und "im Hintergrund" in die Runde 
werfen. Konnte ich auch nie nachvollziehen.

[Stefan F. (Gast)]

Klingt für mich so, als ob der Mikrocontroller defekt sei.
Andererseits kannst du die Pins als GPIO Nutzen. Sie sind also nicht 
defekt.

Dass die I²C Einheit im µC defekt ist, die I/O Pins aber nicht, kann 
eigentlich nicht sein.

[Richard M. (Gast)]

Stefanus F. schrieb:
> Klingt für mich so, als ob der Mikrocontroller defekt sei.
> Andererseits kannst du die Pins als GPIO Nutzen. Sie sind also nicht
> defekt.
>
> Dass die I²C Einheit im µC defekt ist, die I/O Pins aber nicht, kann
> eigentlich nicht sein.

Das Board wurde vorher mit dem RTOS EUROS betrieben und es funktionierte 
stets I2C. Ich kann mir auch nicht erklären warum jetzt I2C nicht 
funktioniert

[STM Apprentice (Gast)]

Mehmet K. schrieb:
> habe ich nie verstanden, wieso
> man für ein paar Bytes, die man per I2C hin- und herschieben will, nicht
> eine Software-Lösung mit ein paar überschau- und nachvollziehbaren
> Zeilen vorzieht.

Es gibt schon Gründe dagegen:

Man muss ja das I2C-Takten durch Delays im usec Bereich steuern
Wenn man eine Interrupt-intensive Anwendung hat kann ein oft
genutztes Delay die Performance stark ausbremsen bzw zum
erliegen bringen.

Einen Vorteil den ich sehr schätze: man kann praktisch jedes
beliebige Pin-Paar für SCL und SDA verwenden.

[Dr. Sommer (Gast)]

Mehmet K. schrieb:
> Okay, jetzt wird Dr. Sommer kommen und "im Hintergrund" in die Runde
> werfen. Konnte ich auch nie nachvollziehen.

Das ist leicht zu erklären. Wenn du parallel noch andere zeitkritische 
Aufgaben laufen hast, möchte man keine Zeit in Warteroutinen des 
Soft-I²C verschwenden. "Den Not-Aus kann ich gerade leider nicht 
durchführen, ich muss noch Statusinformationen ans I²C-Display senden" 
wäre nicht so gut.

[Stefan F. (Gast)]

Ich möchte nochmal anregen, mein Programm wirklich 1:1 zu verwenden. 
Soweit ich erkennen kann, hast du meinen Code irgendwie in deinen 
eingebettet. Die Problemursache könnte außerhalb der von Dir gezeigten 
Zeilen liegen.

Soll ich Dir ein *.bin File von meinem Programm schicken, meinst du das 
könnte helfen?

[STM Apprentice (Gast)]

Allerdings lassen sich bei I2C die Delays ja durchaus "interuptible"
gestalten denn der Bus verlangt nicht eine strenge Taktung wie
(z.B. bei Soft-Serial), da er bei den meisten Bausteinen auch
pseudo-statisch funktioniert.

[Richard M. (Gast)]

Stefanus F. schrieb:
> Soll ich Dir ein *.bin File von meinem Programm schicken, meinst du das
> könnte helfen?

Wäre vll nicht schlecht. Ich wär für jegliche Hilfe dankbar. Ich bastel 
hier ständig rum und versuche den Fehler zu finden. Nachdem die GPIOS 
gehen kann es nur anderweitig Komplikationen geben

[Stefan F. (Gast)]

Richard M. schrieb:
>> Soll ich Dir ein *.bin File von meinem Programm schicken, meinst du das
>> könnte helfen?
>  Wäre vll nicht schlecht.

Ich melde mich heute Abend wieder, wenn ich zu hause bin. Dann mach ich 
das für dich fertig.

[Stefan F. (Gast)]

Wie versprochen ist hier das Lauffähige Programm.

Ich habe es ein bisschen erweitert, damit eine LED an PCA5 oder PC13 
blinkt und damit die I²C Kommunikation endlos oft wiederholt wird.

Da kein Slave angeschlossen ist, wird die Adresse nicht mit ACK 
beantwortet, so dass die Kommunikation an dieser Stelle abgebrochen 
wird.

int main(void)
{
    // Configure PA5 and PC13 for blinking LED
    SET_BIT(RCC->APB2ENR, RCC_APB2ENR_IOPAEN);
    SET_BIT(RCC->APB2ENR, RCC_APB2ENR_IOPCEN);
    MODIFY_REG(GPIOA->CRL, GPIO_CRL_CNF5 + GPIO_CRL_MODE5, GPIO_CRL_MODE5_0);
    MODIFY_REG(GPIOC->CRH, GPIO_CRH_CNF13 + GPIO_CRH_MODE13, GPIO_CRH_MODE13_0);

    // Enable Port B and alternate functions for I²C
    SET_BIT(RCC->APB2ENR, RCC_APB2ENR_IOPBEN);
    SET_BIT(RCC->APB2ENR, RCC_APB2ENR_AFIOEN);

    // Initialize I2C1, no fast mode, APB1 clock is 8 MHz
    i2c_init(I2C1, false, 8000000);

    // I2C uses PB6=SCL, PB7=SDA, alternate function open-drain 2 MHz
    MODIFY_REG(GPIOB->CRL, GPIO_CRL_CNF6 + GPIO_CRL_MODE6, 
        GPIO_CRL_CNF6_0 + GPIO_CRL_CNF6_1 + GPIO_CRL_MODE6_1);
    MODIFY_REG(GPIOB->CRL, GPIO_CRL_CNF7 + GPIO_CRL_MODE7, 
        GPIO_CRL_CNF7_0 + GPIO_CRL_CNF7_1 + GPIO_CRL_MODE7_1);

    // Send and receive buffer
    uint8_t send_buffer[4] = { 10, 20, 30, 40 };
    uint8_t receive_buffer[9];

    for (;;)
    {
        delay(200);

        // Both LED HIGH
        WRITE_REG(GPIOA->BSRR, GPIO_BSRR_BS5);
        WRITE_REG(GPIOC->BSRR, GPIO_BSRR_BS13);

        // Communicate with slave address 8: send 4 bytes, then receive 9 bytes
        int received = i2c_communicate(I2C1, 8, send_buffer, 4, receive_buffer,    9);

        delay(200);

        // Both LED LOW
        WRITE_REG(GPIOA->BSRR, GPIO_BSRR_BR5);
        WRITE_REG(GPIOC->BSRR, GPIO_BSRR_BR13);
    }

}

[Mehmet K. (mkmk)]

Dr. Sommer schrieb:
> "Den Not-Aus kann ich gerade leider nicht
> durchführen, ich muss noch Statusinformationen ans I²C-Display senden"
> wäre nicht so gut.

Also von Dir haette ich jetzt erwartet, dass Du den Not-Aus an ein 
Interrupt anbindest.

[Stefan F. (Gast)]

Richard,
falls du mein Codebeispiel erneut von meiner Homepage herunter lädst, 
beachte bitte, dass ich inzwischen die Konfiguration der I/O Pins in die 
i2c_init() Funktion verschoben habe. Macht Sinn, oder?

[Dr. Sommer (Gast)]

Mehmet K. schrieb:
> Also von Dir haette ich jetzt erwartet, dass Du den Not-Aus an ein
> Interrupt anbindest.

Und wenn es kein simpler Taster ist, sondern eine komplizierte 
Sensorauswertung? z.B. ein BMS welches regelmäßig alle Zelltemperaturen 
abfragt um Dinge wie Derating zu berechnen und manchmal eben auch 
Übertemperatur.

Ohne RTOS kann man nur einen Task haben der lange/blockierend läuft 
(main-Schleife). Alles andere muss dann in Interrupts. Wenn die Schleife 
schon blockiert ist (z.B. mit FAT32-und SD-Karten Ansteuerung oder 
Netzwerkanbindung) kann man die nicht auch noch mit I2C belegen.

Selbst wenn es nicht um Latenzen geht - vielleicht möchte man die 
Leistung des Prozessors komplett ausnutzen (z.B. DSP), wenn man da jede 
Menge Zeit in Warteschleifen vertrödelt kann das knapp werden.

Dann gibt es noch den Aspekt der Leistungsaufnahme - busy waiting 
Schleifen verbrauchen sinnlos Strom. Da kann man besser den Prozessor 
ständig schlafen legen und nur via Interrupt aufwecken wenn was 
passieren muss.

Oder eben doch mit RTOS. Aber auch da verwendet man eher nicht blinde 
Warteschleifen sondern weckt den Thread via Interrupt auf.

[Stefan F. (Gast)]

Dr. Sommer schrieb:
> Ohne RTOS kann man nur einen Task haben der lange/blockierend läuft
> (main-Schleife).

Das stimmt nicht. Multitasking ist durchaus auch ohne RTOS (und ähnliche 
Konstrukte) möglich. Windows 3.11 und Android haben es uns jahrelang 
vorgemacht. Siehe https://www.mikrocontroller.net/articles/Statemachine 
und http://stefanfrings.de/multitasking_arduino/index.html

[Dr. Sommer (Gast)]

Stefanus F. schrieb:
> Das stimmt nicht. Multitasking ist durchaus auch ohne RTOS (und ähnliche
> Konstrukte) möglich.

Leider kann man in State Machines nicht busy warten. Mit Interrupt 
basierten (Hardware) I2C würde man eben genau eine FSM implementieren - 
ohne Warten.

[Stefan F. (Gast)]

Dr. Sommer schrieb:
> Leider kann man in State Machines nicht busy warten.

Korrekt. Mein Code-Beispiel ist in dieser Hinsicht also suboptimal.

[Dr. Sommer (Gast)]

Stefanus F. schrieb:
> Windows 3.11 und Android haben es uns jahrelang vorgemacht.

Windows 3.11 hatte kooperatives Multitasking. Ob der Kontextwechsel 
aktiv oder per Timer Interrupt ausgelöst wird ist an der Stelle egal. 
Wie Android mit Linux etwas anderes als präemptives Multithreading 
gemacht haben soll weiß ich nicht.

[Stefan F. (Gast)]

Dr. Sommer schrieb:
> Wie Android mit Linux etwas anderes als präemptives Multithreading
> gemacht haben soll weiß ich nicht.

Android Apps (die ganze Java VM) liefen lange Zeit Single-Threaded mit 
kooperativem Multitasking. Präemptives Multithreading gab es nur einen 
Layer darunter im nativen Code.

[Stefan F. (Gast)]

Richard M. schrieb:
> i2c_init(I2C1, false, 72000000)

Ich denke, das kann nicht sein. Der APB1 Bus darf mit maximal 36Mhz 
getaktet werden. Hast du den AHB und APB1 Prescaler korrekt eingestellt?

Ich zitiere aus dem Referenzhandbuch:
"The FREQ bits must be configured with the APB clock frequency value 
(I2C peripheral connected to APB). The FREQ field is used by the 
peripheral to generate data setup and hold times compliant with the I2C 
specifications. The minimum allowed frequency is 2 MHz, the maximum 
frequency is limited by the maximum APB frequency and cannot exceed 50 
MHz (peripheral intrinsic maximum limit)."

Es wäre angenehm, zu erfahren, ob mein *.bin File bei Dir läuft (I2C1 
auf PB6 und PB7).

[Bene N. (klia)]

Stefanus F. schrieb:
>
> Es wäre angenehm, zu erfahren, ob mein *.bin File bei Dir läuft (I2C1
> auf PB6 und PB7).

Leider nicht... Ich weiß nicht woran es liegt... Ich verzweifle langsam

[Stefan F. (Gast)]

Benjamin N. schrieb:
>> Es wäre angenehm, zu erfahren, ob mein *.bin File bei Dir läuft (I2C1
>> auf PB6 und PB7).
>
> Leider nicht... Ich weiß nicht woran es liegt... Ich verzweifle langsam

Riecht nach Hardwarefehler. Blinkt denn wenigstens die LED an PA5 oder 
PC13?

[Bene N. (klia)]

Stefanus F. schrieb:

> Riecht nach Hardwarefehler. Blinkt denn wenigstens die LED an PA5 oder
> PC13?

Wie beschrieben, nein, auch gar nicht möglich aufgrund unterschiedlicher 
Boards. Ich schreibe gerade das zip-File um, um es dann zu testen

[Frank M. (ukw) (Moderator)]

Benjamin N. schrieb:
> Leider nicht... Ich weiß nicht woran es liegt...

Blöde Frage: Pullups an SDA & SCL existieren aber, oder?

[Stefan F. (Gast)]

Benjamin N. schrieb:
> Wie beschrieben, nein, auch gar nicht möglich aufgrund unterschiedlicher
> Boards.

Wie meinst du das? Weil er ein anderes Board hat kann es unmöglich 
defekt sein?

[Bene N. (klia)]

Frank M. schrieb:
> Benjamin N. schrieb:
>> Leider nicht... Ich weiß nicht woran es liegt...
>
> Blöde Frage: Pullups an SDA & SCL existieren aber, oder?

Ja, 4,7k jeweils.

[Bene N. (klia)]

Stefanus F. schrieb:
> Benjamin N. schrieb:
>> Wie beschrieben, nein, auch gar nicht möglich aufgrund unterschiedlicher
>> Boards.
>
> Wie meinst du das? Weil er ein anderes Board hat kann es unmöglich
> defekt sein?

Nein, defekt wie per Mail beschrieben kann es nicht sein!

Wenn ich das alte RTOS aufspiele funktioniert es tadellos

[Stefan F. (Gast)]

Bene N. schrieb:
> Nein, defekt wie per Mail beschrieben kann es nicht sein!

Wenn aber weder die Hardware defekt ist, noch mein Beispielprogramm (was 
ich bewiesen habe), dann muss wohl ein Messfehler vorliegen.

Besorge Dir mal schleunigst ein Nucleo64-F103RB Board, damit du andere 
Hardware zum Vergleichen hast. Kostet nur ca 15€.

[Bene N. (klia)]

Also ich hab jetzt einen kleinen Fortschritt. Er schickt zumindest 
schonmal ein Start-Bit... Das Signal geht von High auf Low aber das wars 
dann auch schon. Ich benutze das Programm von Stefanus.

Main wurde abgeändert in:

int main(void)
{
    // Enable Port B and alternate functions for I²C
    SET_BIT(RCC->APB2ENR, RCC_APB2ENR_IOPBEN);
    SET_BIT(RCC->APB2ENR, RCC_APB2ENR_AFIOEN);

    // Initialize I2C1, no fast mode, APB1 clock is 8 MHz
    i2c_init(I2C1, false, 8000000);

    AFIO->MAPR |= AFIO_MAPR_I2C1_REMAP;
    // I2C uses PB6=SCL, PB7=SDA, alternate function open-drain 2 MHz
    // Must be done after the I2C initialization otherwise the I/O pins would start with wrong logic level
    MODIFY_REG(GPIOB->CRH, GPIO_CRH_CNF8 + GPIO_CRH_MODE8, GPIO_CRH_CNF8_0 + GPIO_CRH_CNF8_1 + GPIO_CRH_MODE8_1);
    MODIFY_REG(GPIOB->CRH, GPIO_CRH_CNF9 + GPIO_CRH_MODE9, GPIO_CRH_CNF9_0 + GPIO_CRH_CNF9_1 + GPIO_CRH_MODE9_1);

    uint8_t send_buffer[4] = { 10, 20, 30, 40 };
    uint8_t receive_buffer[9];

    for (;;)
    {
        delay(200);

        // Communicate with slave address 8: send 4 bytes, then receive 9 bytes
        int received = i2c_communicate(I2C1, 0xA8, send_buffer, 4, receive_buffer, 9);

        delay(200);

    }

}

Jetzt bleibt er hier hängen:

while (!READ_BIT(registerStruct->SR1, I2C_SR1_ADDR))             // wait until address has been sent
        {
            if (READ_BIT(registerStruct->SR1, I2C_SR1_AF))
            {
                // did not receive ACK after address
                goto error;
            }
        }

Liegt vermutlich an der falschen Adresse, aber immerhin ein Fortschritt. 
Was war der Fehler? Bisher keinen entdeckt. Plötzlich gigns...

[Stefan F. (Gast)]

Bene N. schrieb:
> Liegt vermutlich an der falschen Adresse

Nein, er muss zumindest die ganze Adresse senden und das ACK (oder NAK) 
einlesen, so wie ich das weiter oben in meinem Screenshot von Logic 
Analyzer gezeigt habe.

Mit wie viel MHz wird denn dein ABP1 Bus konfiguriert?
Ich vermute, dass deine I²C Schnittstelle sich aufhängt, weil sie keine 
funktionierende Takt-Konfiguration hat. In meinem Beispielprogramm wird 
die Default-Vorgabe (nach Reset) verwendet, und das sind 8MHz.

In deinem umgeschriebenen Quelltext waren es zuerst 72MHz, dann 8MHz. 
Die meisten Leute benutzen hingegen das maximal mögliche, das wären 
36MHz. Ich denke, dass du die entscheidenden Code-Zeilen (die dafür 
verantwortlich sind) immer noch nicht gezeigt hast.

[Marc V. (Firma: Vescomp) (logarithmus)]

Bene N. schrieb:
> Liegt vermutlich an der falschen Adresse, aber immerhin ein Fortschritt.
> Was war der Fehler? Bisher keinen entdeckt. Plötzlich gigns...

 Man, probiere es doch mal mit HAL, dann weisst du wenigstens ob es
 ein Soft- oder Hardware Fehler ist.

[Bene N. (klia)]

Stefanus F. schrieb:

> Mit wie viel MHz wird denn dein ABP1 Bus konfiguriert?
> Ich vermute, dass deine I²C Schnittstelle sich aufhängt, weil sie keine
> funktionierende Takt-Konfiguration hat. In meinem Beispielprogramm wird
> die Default-Vorgabe (nach Reset) verwendet, und das sind 8MHz.
>
Sind auf 36MHz und habe ich geändert. Die Init ist in stm32f10x_rcc.

static void SetSysClockTo72(void)
{
  __IO uint32_t StartUpCounter = 0, HSEStatus = 0;
  
  /* SYSCLK, HCLK, PCLK2 and PCLK1 configuration ---------------------------*/    
  /* Enable HSE */    
  RCC->CR |= ((uint32_t)RCC_CR_HSEON);
 
  /* Wait till HSE is ready and if Time out is reached exit */
  do
  {
    HSEStatus = RCC->CR & RCC_CR_HSERDY;
    StartUpCounter++;  
  } while((HSEStatus == 0) && (StartUpCounter != HSE_STARTUP_TIMEOUT));

  if ((RCC->CR & RCC_CR_HSERDY) != RESET)
  {
    HSEStatus = (uint32_t)0x01;
  }
  else
  {
    HSEStatus = (uint32_t)0x00;
  }  

  if (HSEStatus == (uint32_t)0x01)
  {
    /* Enable Prefetch Buffer */
    FLASH->ACR |= FLASH_ACR_PRFTBE;

    /* Flash 2 wait state */
    FLASH->ACR &= (uint32_t)((uint32_t)~FLASH_ACR_LATENCY);
    FLASH->ACR |= (uint32_t)FLASH_ACR_LATENCY_2;    

 
    /* HCLK = SYSCLK */
    RCC->CFGR |= (uint32_t)RCC_CFGR_HPRE_DIV1;
      
    /* PCLK2 = HCLK */
    RCC->CFGR |= (uint32_t)RCC_CFGR_PPRE2_DIV1;
    
    /* PCLK1 = HCLK */
    RCC->CFGR |= (uint32_t)RCC_CFGR_PPRE1_DIV2;

[Bene N. (klia)]

Anbei mal ein Scope… Mehr macht er nicht :-(

Dabei war die Scope-Länge 20 Sekunden. Die Adresse 168 und das Byte 
10...

[Stefan F. (Gast)]

Was ist da los? Warum sind die Flanken so breit dargestellt? Ausserdem 
müsste SCL 5µs nach SDA auf Low gehen. Bei Dir ist der Zeitabstand viel 
zu gering. Das ist der dritte deutliche Hinweis auf fehlerhafte 
Takt-Konfiguration.

Es wäre wirklich hilfreich wenn du dein ganzes Programm zeigen 
würdest, damit das Raten aufhört. Die entscheidenden Zeilen fehlen schon 
wieder - ich kann nicht sehen, wie die PLL und der I2c Takt konfiguriert 
wurden.

Ich habe Dir erneut mein funktionierendes *.bin File angehängt, dieses 
mal mit Remapping auf PB8/9. Probiere es aus. (Der Kommentar "no pin 
remapping" ist falsch)

[Richard M. (Gast)]

Ich habe es soeben auf den Controller geladen. Beide Ausgänge lediglich 
auf HIGH. Ich werde morgen mal das Programm hochladen

[Bene N. (klia)]

Anbei mein File

[Bene N. (klia)]

Anbei nochmal

[Stefan F. (Gast)]

Bene N. schrieb:
> Anbei mein File

Was soll ich jetzt damit anfangen?

Ohne Quelltext kann ich es nicht analysieren und ohne eine Hardware kann 
ich es wahrscheinlich nicht ausführen. bzw: Um zu ermitteln, ob das 
Programm auf meiner Hardware ausführbar wäre, bräuchte ich den 
Quelltext.

Selbst wenn ich es auf meiner Hardware ausführen kann, kommt dabei nur 
eine Aussage wie "geht" oder "geht nicht" heraus. Beide Ergebnisse 
bringen Dich nicht weiter.

Langer Rede kurzer Sinn: Ich brauche immer noch deinen kompletten 
Quelltext.

[Bene N. (klia)]

Das ist mit dem obigen File aber auf Pins 6 und 7... Ich brauche aber 8 
und 9 und da funktioniert einfach gar nichts :-(

[Stefan F. (Gast)]

Bene N. schrieb:
> Das ist mit dem obigen File aber auf Pins 6 und 7... Ich brauche
> aber 8
> und 9 und da funktioniert einfach gar nichts :-(

Junge Junge, ich habe Dir ein *.bin File gegeben, dass nachweislich auf 
Pin 8 und 9 kommuniziert. Hast du mein Foto und die Screenshots nicht 
gesehen?

[Bene N. (klia)]

Stefanus F. schrieb:
> Bene N. schrieb:
>> Das ist mit dem obigen File aber auf Pins 6 und 7... Ich brauche
>> aber 8
>> und 9 und da funktioniert einfach gar nichts :-(
>
> Junge Junge, ich habe Dir ein *.bin File gegeben, dass nachweislich auf
> Pin 8 und 9 kommuniziert. Hast du mein Foto und die Screenshots nicht
> gesehen?

Natürlich hab ich das... Dennoch gibt er auf Pin 8 und 9 nichts aus!!!

[Stefan F. (Gast)]

Bene N. schrieb:
> Stefanus F. schrieb:
>> Bene N. schrieb:
>>> Das ist mit dem obigen File aber auf Pins 6 und 7... Ich brauche
>>> aber 8
>>> und 9 und da funktioniert einfach gar nichts :-(
>>
>> Junge Junge, ich habe Dir ein *.bin File gegeben, dass nachweislich auf
>> Pin 8 und 9 kommuniziert. Hast du mein Foto und die Screenshots nicht
>> gesehen?
>
> Natürlich hab ich das... Dennoch gibt er auf Pin 8 und 9 nichts aus!!!

Dann musst du mal deine Dateien sortieren. Das kann unmöglich sein. Ein 
Programm, das bei mir auf PB8/9 Ausgaben macht*, kann unmöglich bei Dir 
stattdessen PB6/7 verwenden.

*) Was ich wieder anhand von Foto und Screenshot nachgewiesen habe

[Bene N. (klia)]

Stefanus F. schrieb:
> Dann musst du mal deine Dateien sortieren. Das kann unmöglich sein. Ein
> Programm, das bei mir auf PB8/9 Ausgaben macht*, kann unmöglich bei Dir
> stattdessen PB6/7 verwenden.
>
> *) Was ich wieder anhand von Foto und Screenshot nachgewiesen habe

Ich habe auf dem EVAL Board Pin 6 und 7 überprüft und bekomme Daten 
siehe meinen Scope2. Ändere ich aber die Pins auf 8 und 9 wird nichts 
mehr ausgegeben. Das hat doch nichts mit den *.bin zu tun.

[Stefan F. (Gast)]

Bene N. schrieb:
> Anbei nochmal

Na endlich!

Du hast also nun mein Programmbeispiel 1:1 übernommen und in deine IDE 
eingebaut. Irgendwelchen Fremden Code, der irgend etwas am Takt herum 
fummelt, habe ich da jetzt nicht mehr entdeckt.

Laut deinem Screenshot vom Logic Analyzer läuft es auch, aber auf den 
falschen Pins. Das kann bei dem Quelltext aber nicht sein. Hast du etwa 
vergessen, es nach Aktivierung des Remappings zu compilieren oder zu 
übertragen?

Mit deinem Projekt stimmt etwas nicht. Es scheint, als ob du die CMSIS 
Dateiena alle doppelt drin hast, einmal im Hauptverzeichnis und dann 
nochmal im CMSIS Verzeichnis. Ob dass die Fehlerursache ist, weiß ich 
nicht.

[Bene N. (klia)]

Stefanus F. schrieb:
> Mit deinem Projekt stimmt etwas nicht. Es scheint, als ob du die CMSIS
> Dateiena alle doppelt drin hast, einmal im Hauptverzeichnis und dann
> nochmal im CMSIS Verzeichnis. Ob dass die Fehlerursache ist, weiß ich
> nicht.

Nein wird schon richtig kompiliert und wird auch geremapped aber es 
kommt einfach nix an den Pins an.

Ich entfernte CMSIS-Ordner aber ändert nichts.

[Stefan F. (Gast)]

Es kann doch nicht sein, dass das Remapping trotz fehlerfreier Hardware 
nur auf deiner Hardware nicht funktioniert. Ich bin jetzt echt ratlos.

[Bene N. (klia)]

Stefanus F. schrieb:
> Es kann doch nicht sein, dass das Remapping trotz fehlerfreier Hardware
> nur auf deiner Hardware nicht funktioniert. Ich bin jetzt echt ratlos.

Ich eben auch... Ich weiß nicht woran es liegt... Hab einen 4,7k an 
beiden Pins als PullUp. Es ist GENAU dein Programm. Pin 6 und 7 
funktionieren, sobald ich remappe geht nichts mehr

[Bene N. (klia)]

Das Startbit sendet er noch, aber nicht die Adresse... Und das versteh 
ich überhaupt nicht

[Stefan F. (Gast)]

Bene N. schrieb:
> Das Startbit sendet er noch

Ja, aber mit falschem Timing (die beiden Flanken kommen zu schnell 
nacheinander). Und auch diese Messung zeigt wieder so einen auffällig 
breiten Balken bei der Zeitmarke +10µs. Also ob das Signal dort mehrfach 
ganz schnell zwischen High und Low hin und her wechselt.

Die Frage ist, ob das so vom µC kommt, oder von anderen Bauteilen, die 
am Bus hängen. Kannst du die Leitungen unterbrechen?

> Es ist GENAU dein Programm

Das sehe ich jetzt auch anhand deines ZIP Files. Ich dachte erst, dass 
deine IDE womöglich noch Code zur Takt-Konfiguration hinzu fügt, aber 
das ist ganz sicher nicht der Fall.

[Bene N. (klia)]

Also es hing noch ein US dran... Ja. Habe jetzt die VErbindung getrennt. 
Allerdings liegen SCL und SDA jetzt nicht mehr auf HIGH sondern LOW. 
Jetzt kann ich mit LA nichts mehr messen

[Bene N. (klia)]

Ok Stefanus... Ich glaub ich hab den Fehler gefunden... Ich berichte dir 
sobald sich das bestätigt hat...

[Stefan F. (Gast)]

Bene N. schrieb:
> Allerdings liegen SCL und SDA jetzt nicht mehr auf HIGH sondern LOW.

Die Pull-Up Widerstände müssen dran bleiben. Das kannst du ja 
provisorisch machen.

> Ich glaub ich hab den Fehler gefunden
> Ich berichte dir sobald sich das bestätigt hat

Ich bin sehr neugierig auf des Rätsels Lösung.

[Stefan F. (Gast)]

Ich habe in zwischen per Email die Information bekommen, dass doch ein 
HW Fehler vorliegt. Die Platine wurde falsch bestückt, so dass effektiv 
die Pull-Up Widerstände fehlten und ein Widerstand die Leitung SDA mit 
SCL verbunden hatte.

[Yo (Gast)]

Nach 3 Tagen habe ich bei mir einen Fehler gefunden. Mag dieser hier 
auch sein. Die Lösung bei mir war ein Reset vom I2C Modul zu machen, 5ms 
warten, dann nochmal konfigurieren, warten nochmal 5ms, dann enable des 
Modules. Klingt  bescheuert, ist aber so.

[Stefan F. (Gast)]

Yo schrieb:
> Die Lösung bei mir war ein Reset vom I2C Modul zu machen, 5ms
> warten, dann nochmal konfigurieren, warten nochmal 5ms, dann enable des
> Modules.

Ich würde dir einen Blick ins Errata Dokument zu werfen. Wenn du die 
Schnittstelle so benutzt, wir dort beschrieben ist, sind solche 
Wiederholungen nicht nötig.

> Klingt bescheuert, ist aber so.

Die Hardware ist halt ein bisschen buggy.