STM32F103RFT6 I2C2 keine Funktion

[Bernd S. (soundgott)]

Hallo auch,
ich brüte schon seit ein paar Tagen an der I2C Kommunikation (mit 
EEPROM, Display) an einem STM32F103RFT6. Die Pins PB10/11 führen die 
Signale SCL/SDA des 2. I2C Interfaces (I2C2). Pullups 3.6k sind dran. 
Selbst in einem minimalsten Testprogramm regt sich an den Leitungen 
nichts, dauerhafter Highpegel. Im Debugger sind alle notwendigen 
Register der RCC, GPIOB und I2C2 korrekt gesetzt. Gleiches Testprogramm 
für I2C1 konfiguriert, läuft ohne Probleme. Ich habe schon sämtliche 
Errata's und "googles" durch, nichts gefunden. Meine Hoffnung liegt nun 
hier. Hat jemand eine evtl Lösung?

[Patrick (dereine)]

Moinsen,

wurde auch beim richtigen Package für die physischen Pins geguckt?

Laut Datenblatt liegen I2C2 SCL/SDA an Pin 29/30 für LQFP-64.
Nicht, das versehentlich bei LQFP-100 geguckt wurde und 47/48 vewendet 
wird.

Grüße,
derEine

[Kilo S. (kilo_s)]

Sollen wir Hellsehen?

Zeig deinen CODE!

[Bernd S. (soundgott)]

Patrick schrieb:
> Laut Datenblatt liegen I2C2 SCL/SDA an Pin 29/30 für LQFP-64.
> Nicht, das versehentlich bei LQFP-100 geguckt wurde und 47/48 vewendet
> wird.

Einwand berechtigt, ist aber korrekt angeschlossen (SCL: pin 29, PB10 
und SDA: pin 30, PB11)
Getestet wurde auf 2 verschiedenen Boards mit dem gleichen negativen 
Ergebnis.

Kilo S. schrieb:
> Sollen wir Hellsehen?
>
> Zeig deinen CODE!

Der Code für die Initialisierung, Nutzung der I2C-Schnittstellen dürfte 
den Wissenden bekannt sein. Es wurde mit verschiedenen Tests geprüft: 
Bare-Metal, HAL, StdPeripherie, auch mit STMCube erzeugter Code, alles 
mit gleichem Ergebnis. Das Ding rührt sich nicht.

[Patrick (dereine)]

Gibt es sonst eventuell ein Konflikt mit einer aktivierten USART3 
Schnittstelle?

[Stefan S. (chiefeinherjar)]

Bernd S. schrieb:
> Patrick schrieb:
>> Laut Datenblatt liegen I2C2 SCL/SDA an Pin 29/30 für LQFP-64.
>> Nicht, das versehentlich bei LQFP-100 geguckt wurde und 47/48 vewendet
>> wird.
>
> Einwand berechtigt, ist aber korrekt angeschlossen (SCL: pin 29, PB10
> und SDA: pin 30, PB11)
> Getestet wurde auf 2 verschiedenen Boards mit dem gleichen negativen
> Ergebnis.


Gut, an der Hardware liegt es nicht.

Bernd S. schrieb:
> Kilo S. schrieb:
>> Sollen wir Hellsehen?
>>
>> Zeig deinen CODE!
>
> Der Code für die Initialisierung, Nutzung der I2C-Schnittstellen dürfte
> den Wissenden bekannt sein. Es wurde mit verschiedenen Tests geprüft:
> Bare-Metal, HAL, StdPeripherie, auch mit STMCube erzeugter Code, alles
> mit gleichem Ergebnis. Das Ding rührt sich nicht.

Gut, die Software ist auch ausgeschlossen.

Also muss der Bug im Silizium des Chips sitzen - denn an dir bzw. 
deiner Schaltung (die du geheim hältst) und deinem Code (den du 
ebenfalls geheim hältst) kann es schließlich nicht liegen. Beides ist 
schließlich garantiert fehlerfrei - es stammt ja schließlich von dir.
Ergo können wir dir hier nicht weiterhelfen.

[Kilo S. (kilo_s)]

Ah, der fehlerfreie perfekte Mensch erbarmt sich zu uns ins niedere 
Forum auf der Suche nach Hilfe die ja unmöglich auf einen seiner Fehler 
zurückzuführen sind!

Langsam aber sicher sind doch 90% der Menschheit noch zu doof einen 
Schuh vol pisse auszuleeren, bei dem die Anleitung dazu auf der Sohle 
steht!

Goodbye, TROLL!

[Bernd S. (soundgott)]

Stefan S. schrieb:
> Gut, die Software ist auch ausgeschlossen.
>
> Also muss der Bug im Silizium des Chips sitzen - denn an dir bzw.
> deiner Schaltung (die du geheim hältst) und deinem Code (den du
> ebenfalls geheim hältst) kann es schließlich nicht liegen. Beides ist
> schließlich garantiert fehlerfrei - es stammt ja schließlich von dir.
> Ergo können wir dir hier nicht weiterhelfen.
 Dabei ist der Code garnicht von mir (CubeMX)

[Bernd S. (soundgott)]

Kilo S. schrieb:
> Ah, der fehlerfreie perfekte Mensch erbarmt sich zu uns ins niedere
> Forum auf der Suche nach Hilfe die ja unmöglich auf einen seiner Fehler
> zurückzuführen sind!

Schwachsinn, habe ich nie behauptet. Warscheinlich ist mein Ersuchen 
doch nur für Leute mit entsprechendem Wissen geeignet!

hier noch ein weiterer Test , nutzt die StdPeriph lib.

[Kilo S. (kilo_s)]

Kein clock keine Pin Definitionen!

Geräteadresse?...

[Alex R. (geneo)]

Du sprichst von Pin 10/11, ich sehe aber nur Pin 6/7 konfiguriert.

[Kilo S. (kilo_s)]

void HAL_I2C_MspInit(I2C_HandleTypeDef* hi2c)
{
  GPIO_InitTypeDef GPIO_InitStruct = {0};

  if(hi2c->Instance == I2C2)
  {
    /* Clocks */
    __HAL_RCC_GPIOB_CLK_ENABLE();
    __HAL_RCC_I2C2_CLK_ENABLE();
    __HAL_RCC_AFIO_CLK_ENABLE();

    /* I2C2 GPIO Configuration: PB10=SCL, PB11=SDA */
    GPIO_InitStruct.Pin = GPIO_PIN_10 | GPIO_PIN_11;
    GPIO_InitStruct.Mode = GPIO_MODE_AF_OD;
    GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_HIGH;
    HAL_GPIO_Init(GPIOB, &GPIO_InitStruct);
  }
}

falsch initialisiert!

F1 benutzt keine Alternate-Function Nummern (GPIO_AF4_I2C2 existiert 
hier nicht)

[Bernd S. (soundgott)]

Alex R. schrieb:
> Du sprichst von Pin 10/11, ich sehe aber nur Pin 7/8 konfiguriert.

Mist, falsches File. Du hast Recht, ändert aber nix.

[Kilo S. (kilo_s)]

Thomas W. schrieb im Beitrag #8010567:
> Eigentlich haette der Compiler auch eine Warnung schicken sollen (16-bit
> vs. 8-Bit).

Daher meine Frage bezüglich der Adresse...

[Kilo S. (kilo_s)]

Bernd S. schrieb:
> Warscheinlich ist mein Ersuchen doch nur für Leute mit entsprechendem
> Wissen geeignet!

Vorsicht, so hochtrabenden können tief Fallen!

[Bernd S. (soundgott)]

Kilo S. schrieb:
> __HAL_RCC_AFIO_CLK_ENABLE();

ist auch richtig, kann weggelassen werden, ändert aber ebenfalls nix.
Damit auch die letzten Zweifel ausgeräumt werden:
Testumgebung: Visual Studio mit Extension VisualDGB (Compiler GCC)
Wie schon gesagt: in der Hardware-Registeransicht sind alle Register von 
I2C2, GPIOB, RCC korrekt gesetzt, aber es passiert nichts. Ich kan 
sehen, dass beim Sendeversuch, d.h. I2C2->DR das zu sendende Datum 
erhält, es bleibt jedoch beim nächsten Singlestep stehen (im Gegenzug 
zum Test mit I2C1)

[Bernd S. (soundgott)]

Kilo S. schrieb:
> Thomas W. schrieb im Beitrag #8010567:
>> Eigentlich haette der Compiler auch eine Warnung schicken sollen (16-bit
>> vs. 8-Bit).
>
> Daher meine Frage bezüglich der Adresse...

???

[Jük P. (tik-tak)]

Bernd S. schrieb:
> aber es passiert nichts.

STM32F103RFT6 bestimmt original?

[Kilo S. (kilo_s)]

CubeMX setzt CR2 oft nur für I2C1 korrekt.

RCC->APB1ENR |= RCC_APB1ENR_I2C2EN;

I2C2->CR2 = 36;   // APB1 Clock in MHz

I2C2 kann mit JTAG/SWD Pins kollidieren, wenn AFIO falsch konfiguriert 
ist.

__HAL_RCC_AFIO_CLK_ENABLE();

//und ob irgendwo remapped wurde
AFIO->MAPR

teste mal:

printf("CR2=%lu\n", I2C2->CR2);
printf("APB1=%lu\n", HAL_RCC_GetPCLK1Freq());

Wenn du mir diese drei Werte gibst, sag ich dir sofort den Fehler:

RCC->CFGR
I2C2->CR2
GPIOB->CRH

[Kilo S. (kilo_s)]

Bernd S. schrieb:
> ???

uint16_t devAddr = 0x50 << 1;   // korrekt

[Bernd S. (soundgott)]

Kilo S. schrieb:
> RCC->CFGR
> I2C2->CR2
> GPIOB->CRH

RCC->CFGR: 0x001d040a
I2C2->CR2: 0x00000024
GPIOB->CRH: 0x2848ff42 (CNF/MODE 10,11 = 0x11)

[Kilo S. (kilo_s)]

Prüfe:

uint32_t busy = I2C2->SR2 & I2C_SR2_BUSY;

Wenn ≠0 → Ursache gefunden.

Typische Gründe:

Slave hält SDA

Pull-ups fehlen / zu schwach

vorheriger Reset mitten im Transfer

Debugger Stop während I2C aktiv.

Fix (offizieller ST Workaround)

I2C2->CR1 |= I2C_CR1_SWRST;
I2C2->CR1 &= ~I2C_CR1_SWRST;

Vor Init Bus freitakten:

// SCL manuell toggeln wenn SDA LOW
for(int i=0;i<9;i++)
{
   SCL_HIGH();
   delay();
   SCL_LOW();
   delay();
}

Direkt nach Init:

printf("SR2 = %04X\n", I2C2->SR2);

Ausgabe:

SR2 = 0002

BUSY Flag gesetzt, Ursache bestätigt.

Füge direkt nach Init ein:(Schnelllösung)

if(I2C2->SR2 & I2C_SR2_BUSY)
{
   I2C2->CR1 |= I2C_CR1_SWRST;
   I2C2->CR1 &= ~I2C_CR1_SWRST;
}

das sollte selbst mit kaputten slaves laufen:

void I2C2_Robust_Init(void)
{
    GPIO_InitTypeDef GPIO_InitStruct = {0};

    /* 1. Clocks aktivieren */
    __HAL_RCC_GPIOB_CLK_ENABLE();
    __HAL_RCC_I2C2_CLK_ENABLE();
    __HAL_RCC_AFIO_CLK_ENABLE();

    /* 2. Pins erstmal als GPIO OpenDrain (manuelle Bus Recovery) */
    GPIO_InitStruct.Pin = GPIO_PIN_10 | GPIO_PIN_11;
    GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_OD;
    GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_HIGH;
    HAL_GPIO_Init(GPIOB, &GPIO_InitStruct);

    HAL_GPIO_WritePin(GPIOB, GPIO_PIN_10|GPIO_PIN_11, GPIO_PIN_SET);
    HAL_Delay(1);

    /* 3. Bus freitakten falls Slave hängt */
    if(!HAL_GPIO_ReadPin(GPIOB, GPIO_PIN_11)) // SDA LOW?
    {
        for(int i=0;i<9;i++)
        {
            HAL_GPIO_WritePin(GPIOB, GPIO_PIN_10, GPIO_PIN_RESET);
            HAL_Delay(1);
            HAL_GPIO_WritePin(GPIOB, GPIO_PIN_10, GPIO_PIN_SET);
            HAL_Delay(1);
        }
    }

    /* STOP Condition erzwingen */
    HAL_GPIO_WritePin(GPIOB, GPIO_PIN_11, GPIO_PIN_RESET);
    HAL_Delay(1);
    HAL_GPIO_WritePin(GPIOB, GPIO_PIN_10, GPIO_PIN_SET);
    HAL_Delay(1);
    HAL_GPIO_WritePin(GPIOB, GPIO_PIN_11, GPIO_PIN_SET);
    HAL_Delay(1);

    /* 4. I2C Hardware Reset */
    I2C2->CR1 |= I2C_CR1_SWRST;
    HAL_Delay(1);
    I2C2->CR1 &= ~I2C_CR1_SWRST;

    /* 5. Pins auf I2C Alternate Function */
    GPIO_InitStruct.Mode = GPIO_MODE_AF_OD;
    HAL_GPIO_Init(GPIOB, &GPIO_InitStruct);

    /* 6. Peripheral Disable */
    I2C2->CR1 &= ~I2C_CR1_PE;

    /* 7. Timing konfigurieren */
    I2C2->CR2 = 36;        // APB1 MHz
    I2C2->CCR = 180;       // 100kHz @36MHz
    I2C2->TRISE = 37;      // laut Datenblatt

    /* 8. Peripheral Enable */
    I2C2->CR1 |= I2C_CR1_PE;

    /* 9. Dummy Read SR2 → Flags reset */
    (void)I2C2->SR2;

    /* 10. BUSY prüfen */
    if(I2C2->SR2 & I2C_SR2_BUSY)
    {
        /* letzter Rettungsversuch */
        I2C2->CR1 &= ~I2C_CR1_PE;
        HAL_Delay(1);
        I2C2->CR1 |= I2C_CR1_PE;
    }
}

[Bernd S. (soundgott)]

Kilo S. schrieb:
> Prüfe:

Danke schonmal, werde es ausgiebig checken und berichten

[Bernd S. (soundgott)]

Bernd S. schrieb:
> Kilo S. schrieb:
>> Prüfe:

soweit geprüft!
anbei Auszug aus dem Quellcode. Seltsam ist, dass die eingebaute 
Scannerfunktion tatsächlich die beiden angeschlossenen Slaves auch mit 
den richtigen Adressen findet. Das Testprogramm eetest() läuft einmal 
durch und bleibt dann beim nächsten Durchlauf in der single_write(0x20, 
0x15)
hängen, wartet auf ein gesetztes TXE Bit, was nicht kommt.

Wie zu sehen, die I2C-Funktionen sind in einer Klasse enthalten.

[Kilo S. (kilo_s)]

Der F1 ist da pingelig.

void CI2C::single_write(uint8_t addr, uint8_t data)
{
    m_pI2C->CR1 |= CR1_START_Set;
    while (!(m_pI2C->SR1 & I2C_SR1_SB));

    I2C_Send7bitAddress(m_pI2C, m_slaveadress, I2C_Direction_Transmitter);

    while (!(m_pI2C->SR1 & I2C_SR1_ADDR));

    volatile uint32_t tmp;
    tmp = m_pI2C->SR1;
    tmp = m_pI2C->SR2;
    (void)tmp;

    while (!(m_pI2C->SR1 & I2C_SR1_TXE));

    m_pI2C->DR = addr;
    while (!(m_pI2C->SR1 & I2C_SR1_BTF));

    m_pI2C->DR = data;
    while (!(m_pI2C->SR1 & I2C_SR1_BTF));

    m_pI2C->CR1 |= CR1_STOP_Set;
}

Hier:

while (!(m_pI2C->SR1) | !(m_pI2C->SR2)) {}

Problem:

| statt ||

prüft das ganze Register statt Flags

ADDR wird nie gelöscht

Der Scanner funktioniert nur zufällig.

Dritter versteckter Bug

In readByte():

m_pI2C->DR = (address << 1) + 0x00;

Das ist Write-Adresse, nicht Read.

Read müsste sein:

(address << 1) | 1

So weit so gut...

[Kilo S. (kilo_s)]

versuchs mal hiermit...

[Bernd S. (soundgott)]

Kilo S. schrieb:
> versuchs mal hiermit...

Hier mal die Resultate aus deinem Beispiel:
Er spricht wieder!!!
da ich auf dem Testboard ein EEPROM habe, dass eine 16bit Adresse 
verlangt, (FM64LC64) habe ich die read/write funktionen noch 
entsprechend ergänzt und siehe da, was man reinschreibt, kommt auch 
wieder raus.
Jetzt muss ich nur noch ergründen, warum mein Code rum zickt
Schon mal Danke Kilo S.