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