STM32 I2C byte lässt sich nicht ändern

[STM32_Noob (Gast)]

Hallo,
Ich habe meinen STM32F030F4 dazu bekommen, die LED Blinken zu lassen.
Allerdings möchte ich den Portexpander PCF8474 zum laufen bekommen.
Mein Programm schreibt 1 Byte (0x55) in den Expander, dieser zeigt auch 
das byte an. Leider kann Ich nicht den den Wert der Variable ändern und 
erneut schreiben. Hier mein Code:

uint8_t buffer[2];

  while (1)
  {
    buffer[0]++;

    HAL_I2C_Master_Transmit(&hi2c1, 0x40, buffer, 1, 100);
    HAL_Delay(1000);
  }

hoffe, das mir jemand damit helfen kann.

mfg

[Horst (Gast)]

Wo ist der Rest vom Programm?

[Stefan F. (Gast)]

In den wenigen Zeilen sehe ich keinen Fehler.

[Martin Antoni (Gast)]

der buffer muss volatile sein

[STM32_Noob (Gast)]

Leider funktioniert es immer noch nicht,
die Variable wird nicht hochgezählt.
der Compiler gibt folgenden Fehler aus:

../Src/main.c(116): warning:  #167-D: argument of type "volatile uint8_t 
*" is incompatible with parameter of type "uint8_t *"

[50c (Gast)]

STM32_Noob schrieb:

> uint8_t buffer[2];
>
>   while (1)
>   {
>     buffer[0]++;
>
>     HAL_I2C_Master_Transmit(&hi2c1, 0x40, buffer, 1, 100);
>     HAL_Delay(1000);
>   }
>

...wie wäre es, aus der Hüfte geschossen, mit

...
HAL_I2C_Master_Transmit(&hi2c1, 0x40, buffer[0], 1, 100);
...

[50c (Gast)]

...und der Tipp mit volatile ist an der Stelle natürlich Blödsinn!

[Horst (Gast)]

Die Frage ist, ob der Fehler nicht im HAL_I2C_Init-Aufruf bzw dem 
I2cHandle liegt.

[50c (Gast)]

Horst schrieb:
> Die Frage ist, ob der Fehler nicht im HAL_I2C_Init-Aufruf bzw dem
> I2cHandle liegt.

dazu schreibt der TO:

STM32_Noob schrieb:
> Mein Programm schreibt 1 Byte (0x55) in den Expander, dieser zeigt auch
> das byte an.

...dann sollte das Init wohl schon funktioniert haben...

[Frank M. (ukw) (Moderator)]

50c schrieb:
> HAL_I2C_Master_Transmit(&hi2c1, 0x40, buffer[0], 1, 100);

50c schrieb:
> ...und der Tipp mit volatile ist an der Stelle natürlich Blödsinn!

Deiner ist aber genauso Blödsinn. HAL_I2C_Master_Transmit erwartet als 
drittes Argument einen Buffer und kein einzelnes Byte.

Warum werden hier Tipps gegeben, für die es überhaupt keine Begründung 
gibt? Wenn man es besser weiß, ist man für jeden Tipp dankbar. Wenn man 
es nicht besser weiß, ist es weise, entweder die Klappe zu halten oder 
den TO dazu zu bewegen, mehr Infos rauszurücken. Rätselraten ist absolut 
nicht zielführend.

Nein: Ich weiß es auch nicht besser, dafür ist der Code-Ausschnitt zu 
dürftig.

[Frank M. (ukw) (Moderator)]

STM32_Noob schrieb:
> HAL_Delay(1000);

Läuft der Systick-Handler überhaupt? Sonst hängt der Delay ewig.

Siehe zum Beispiel:

https://electronics.stackexchange.com/questions/286914/stm32-hal-delay-hangs-with-hal-gettick-0

[STM32_Noob (Gast)]

> Die Frage ist, ob der Fehler nicht im HAL_I2C_Init-Aufruf bzw dem
> I2cHandle liegt.

Ich benutze STM32CubeMX.

Nichts verändert sollte also funktionieren.

[STM32_Noob (Gast)]

> Nein: Ich weiß es auch nicht besser, dafür ist der Code-Ausschnitt zu
> dürftig.
Habe das Programm mal mit angehängt,
Bis auf die Variable und den Programm abschnitt wurde nichts geändert.

Das Programm läuft mehrmals durch, da es auch mehrmals die Werte 
schreibt.
(Allerdings ist es egal, ob der Code in oder außerhalb der While 
Schleife liegt, und er sendet alle 0,4S das Signal)
Den Output vom Logik Analyzer hänge ich euch auch an.

Als IDE benutze Ich keil.

mfg

[Mampf F. (mampf)]

STM32_Noob schrieb:
> Das Programm läuft mehrmals durch, da es auch mehrmals die Werte
> schreibt.
> (Allerdings ist es egal, ob der Code in oder außerhalb der While
> Schleife liegt, und er sendet alle 0,4S das Signal)
> Den Output vom Logik Analyzer hänge ich euch auch an.

Wenn du was anderes auf das I2C rausschreibst - zB 0xaa - dann klappt 
das auch?

[STM32_Noob (Gast)]

> Wenn du was anderes auf das I2C rausschreibst - zB 0xaa - dann klappt
> das auch?
Ja, das geht auch problemlos.
Allerdings glaube Ich, das er den µC immer neustartet.
Da ich das Programm auch Auserhalb und ohne Delay ausführen kann.
Außerdem wartet er keine Sekunde.

[Mampf F. (mampf)]

STM32_Noob schrieb:
> Allerdings glaube Ich, das er den µC immer neustartet.

Oha ... das wäre eine Erklärung.

Aber was ist die Ursache ... Watchdog scheint da keiner an zu sein^^

Hardware-Fehler?

Was hast du da für eine Hardware-Basis?

Schaltplan wäre auch hilfreich.

[STM32_Noob (Gast)]

So, habe jetzt eine Lösung entwickelt.
Scheinbar wurde das Programm nicht richtig abgearbeitet,
sondern der Controller immer wieder resettet.
Durch Zufall bin Ich auf die Passende Lösung gekommen.
Habe gedacht, jemand von euch benutzt den STM32 mit den HAL Librarys.
Leider falsch gedacht... Egal, hier mal die Lösung:

  while (1)
  {

    data[0]++;

    HAL_I2C_Init(&hi2c1);

    HAL_I2C_IsDeviceReady(&hi2c1,0x40,2,100);

    HAL_I2C_Master_Transmit(&hi2c1,0x40,data,1,100);

  }
Damit funktioniert es endlich, und der Logikanalysator zeigt nur noch
Daten an.
Danke für die Mithilfe.

[Harry L. (mysth)]

STM32_Noob schrieb:
> Habe gedacht, jemand von euch benutzt den STM32 mit den HAL Librarys.
> Leider falsch gedacht... Egal, hier mal die Lösung:
>
>   while (1)
>   {
>
>     data[0]++;
>
>     HAL_I2C_Init(&hi2c1);
>
>     HAL_I2C_IsDeviceReady(&hi2c1,0x40,2,100);
>
>     HAL_I2C_Master_Transmit(&hi2c1,0x40,data,1,100);
>
>   }
> Damit funktioniert es endlich, und der Logikanalysator zeigt nur noch
> Daten an.

HAL_I2C_Init(... ist ganz sicher überflüssig - ggf. sogar 
kontraproduktiv an dieser Stelle.

Das wird genau 1 mal VOR der while(1)-Schleife aufgerufen!

HAL_I2C_IsDevReady ist so, wie du das verwendest auch Unfug, da du dich 
um das Ergebnis (Rückgabewert) gar nicht kümmerst.

Wenn du CubeMX nutzt, generier mal einen Report (PDF-Datei) und poste 
den hier.

[Mampf F. (mampf)]

STM32_Noob schrieb:
> Habe gedacht, jemand von euch benutzt den STM32 mit den HAL Librarys.

Den verbuggten Mist HAL? ???

> Leider falsch gedacht...

Ja ... Hab ich meine ersten Schritte mit den STM32 gemacht und fand es 
ganz furchtbar ... Mittlerweile ist alles nach CMSIS migriert und es 
funktioniert alles so wie es soll :) HAL ist ein Monster ?

[STM32_Noob (Gast)]

> Ja ... Hab ich meine ersten Schritte mit den STM32 gemacht und fand es
> ganz furchtbar ... Mittlerweile ist alles nach CMSIS migriert und es
> funktioniert alles so wie es soll :) HAL ist ein Monster ?

Ich habe vorher die guten 8bit AVRs genutzt. Leider sind die für meine 
Anwendungen zu langsam. CMSIS hört sich auch interessant an. Gibt es 
dafür ein gutes Tutorial? Welche IDE nutzt du?

mfg

[Mampf F. (mampf)]

STM32_Noob schrieb:
> Ich habe vorher die guten 8bit AVRs genutzt. Leider sind die für meine
> Anwendungen zu langsam. CMSIS hört sich auch interessant an. Gibt es
> dafür ein gutes Tutorial? Welche IDE nutzt du?

Ja das witzige ist - die meisten Tutorials verwenden CMSIS und ich hatte 
damals echte Probleme, Tutorials zu finden, die HAL verwenden.

Die StdPeriph-Library von ST hat vor HAL noch CMSIS verwendet.

Die gibt es immer noch zum Download:
http://www.st.com/en/embedded-software/stm32-standard-peripheral-libraries.html?querycriteria=productId=LN1939

Bzgl IDE bin ich wohl eine Ausnahme ... Ich verwende Eclipse + 
Gnu-ARM-Plugin + OpenOCD Debugger.

Scheint wohl eine Kombination zu sein, die man selten sieht ... 
Funktioniert aber astrein - und ich hab nur Linux.

[STM32_Noob (Gast)]

Mampf F. schrieb:
> Ja das witzige ist - die meisten Tutorials verwenden CMSIS und ich hatte
> damals echte Probleme, Tutorials zu finden, die HAL verwenden.
>
> Die StdPeriph-Library von ST hat vor HAL noch CMSIS verwendet.
>
> Die gibt es immer noch zum Download:
> 
http://www.st.com/en/embedded-software/stm32-standard-peripheral-libraries.html?querycriteria=productId=LN1939
>
> Bzgl IDE bin ich wohl eine Ausnahme ... Ich verwende Eclipse +
> Gnu-ARM-Plugin + OpenOCD Debugger.
>
> Scheint wohl eine Kombination zu sein, die man selten sieht ...
> Funktioniert aber astrein - und ich hab nur Linux.

Ja, zur HAL Lib habe ich auch sehr wenig brauchbares gefunden.
Werde es mal mir CMSIS versuchen, hoffe es geht einfacher ;).

Benutze zurzeit Keil auf Windows 10,
werde aber auf CoIDE umsteigen, da das besser läuft.

[Mampf F. (mampf)]

STM32_Noob schrieb:
> Ja, zur HAL Lib habe ich auch sehr wenig brauchbares gefunden.
> Werde es mal mir CMSIS versuchen, hoffe es geht einfacher ;).

Ah nebenbei, ich verwende trotzdem CubeMX sehr gerne zur Planung 
meiner GPIOs (bei eigenen Layouts mit STM32) ... Dafür ist es perfekt.

Ich lass mir gelegentlich dann auch noch den Code erzeugen für die 
GPIO-Definitionen und übernehme den Quasi mit ein paar Änderungen (Die 
Funktionen heißen bisserl anders)