STM32F205 cached Register obwohl er keine Caches hat

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Ein interessantes Problem ist mir gestern aufgefallen.

Ab und zu bleibt der I2C hängen bei der while Schleife hier:

uint8_t i2c_rep_start(unsigned int i2c_base, uint8_t addr){

  volatile struct i2c * const i2c = (volatile struct i2c *)i2c_base;
  
  while(i2c->SR1 & SR1_BTF);
  return starting(i2c_base, addr);
}

Mit dem volatile stimmt eigentlich alles und es ist mit -O0 compiliert 
zum debuggen.

Im Debugger sehe ich, dass der CPU Kern SR1 als 0x84 ausließt und im 
Register vorhält.
0x80 für TX not empty und eben 0x04 für BTF.
Jetzt dacht ich, dass dann eben der I2C Bus klemmt, kann ja mal 
vorkommen.

ABER!

Wenn ich jetzt im Debugger den Registerwatch öffne, dann steht da 0x80 
beim SR1.
Jetzt kommts noch besser: wenn ich jetzt nochmal durchsteppe, dann ließt 
er auch 0x80 aus und macht weiter aufm I2C Bus.

Hat da jemand ne Idee?
In den Erratas stehen zwar andere gruselige Dinge, aber nicht dieses 
Problem.

Ich brauch nen Exorzisten!

[Gerd E. (robberknight)]

Mw E. schrieb:
> Wenn ich jetzt im Debugger den Registerwatch öffne, dann steht da 0x80
> beim SR1.

Ich würde dem Debugger an der Stelle nicht unbedingt vertrauen. Wenn der 
Debugger Register auslesen will, kann es zu einigen lustigen Effekten 
kommen die Fehler vorspiegeln wo gar keine sind.

Lies die Register in Deinem Code aus und speichere sie in einem Puffer 
im RAM. Dann lass den Code mit normaler Geschwindigkeit ohne 
Unterbrechung durch den Debugger laufen. Setze Deinen Breakpoint auf 
eine spätere Stelle im Code und schau Dir dann den Inhalt von Deinem 
Puffer an.

[Jim M. (turboj)]

Mw E. schrieb:
> Mit dem volatile stimmt eigentlich alles und es ist mit -O0 compiliert
> zum debuggen.

Zeig mir wie "struct i2c" definiert ist  und ich zeige Dir (vermutlich) 
Deinen Fehler.

Die metrische Tonne Casts bringt hier nix IMHO.

[(prx) A. K. (prx)]

Der Asm-Code dieses Codes?

Was soll es eigentlich bringen, die Adresse als uint zu übergeben und 
überall zu casten? Statt den Parameter gleich richtig zu definieren. 
Ganz allgemein würde ich empfehlen, Casts möglichst sparsam einzusetzen.

[foobar (Gast)]

Sicher, dass der Test (warten auf 0) richtig rum ist?

[M. Н. (Gast)]

Kann auch ein Glitch in der Hardware sein. Hatte sowas beim SDIO Modul 
schon. Habe das Status Register in einer Dauerschleife gepollt.
Mit -O0 lief alles. Sobald man den Code auf -O3 gestellt hat, hat er 
immer nen CRC Fehler angezeigt, obwohl die Kommunikation aufm 
Logicanalyzer korrekt aussah...

Ich musste zuerst darauf warten, bis das Kommando fertig war, und dann 
die Status Flags lesen. Die Flags flackern wohl während des Sendens ab 
und zu hin und her. Das war eine Sucherei.

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Vielen Dank für die Antworten, leider komme ich erst jetzt zum 
Antworten.

foobar schrieb:
> Sicher, dass der Test (warten auf 0) richtig rum ist?
Genau das wars, BTF soll ja nicht gesetzt sein.
Man sollt eben nicht 1 Uhr morgens noch Coden.

Gerd E. schrieb:
> Mw E. schrieb:
>> Wenn ich jetzt im Debugger den Registerwatch öffne, dann steht da 0x80
>> beim SR1.
>
> Ich würde dem Debugger an der Stelle nicht unbedingt vertrauen. Wenn der
> Debugger Register auslesen will, kann es zu einigen lustigen Effekten
> kommen die Fehler vorspiegeln wo gar keine sind.

Registerlesen beim I2C kann ja durchaus an der Statemachine rumspielen 
(zB SR2 lesen resetet das ADDR Bit).
An der Stelle ist da zwar nichts im DaBla Dokumentiert, aber wer weis 
was ST da ins Silizium gegossen hat.
Jedenfalls wird das auslesen der Register an der Statemachine gespielt 
haben zB durch das DataRegister lesen und schon hats das BTF geflippt.
Wieso hat der PeripheralBus eigentlich keine Leitung für "das ist jetzt 
eine Registerwatch Debugauslesung, bitte behalte die internen States der 
Statemachine bei" ?! Wär doch mal ne gute Neuerung.

Jim M. schrieb:
> Die metrische Tonne Casts bringt hier nix IMHO.
Verzweiflungstat ;)
Ein volatile cast würde reichen.

Jim M. schrieb:
> Zeig mir wie "struct i2c" definiert ist  und ich zeige Dir (vermutlich)
> Deinen Fehler.
Bittesehr:

struct i2c {
  unsigned int CR1;
  unsigned int CR2;
  unsigned int OAR1;
  unsigned int OAR2;
  unsigned int DR;
  unsigned int SR1;
  unsigned int SR2;
  unsigned int CCR;
  unsigned int TRISE;
};

es bringt übrigens nichts dort volatile vor das struct zu schreiben, 
dann meckert der Compiler zurecht mit:
"periph/i2c_regdefs.h:14:1: warning: useless type qualifier in empty 
declaration"
Erst durch das Casten wird das volatile, ist das struct volatile, so 
auch seine Inhalte.

A. K. schrieb:
> Was soll es eigentlich bringen, die Adresse als uint zu übergeben und
> überall zu casten? Statt den Parameter gleich richtig zu definieren.
> Ganz allgemein würde ich empfehlen, Casts möglichst sparsam einzusetzen.

Es gibt ja nicht nur den einen I2C, also übergeb ich die Basisadresse 
des I2C und lege dann das struct über die Register.
Da könnt man jetzt nochn enum nehmen.
Direkt nen Pointer aufn struct übergeben könnt man auch, aber dann muss 
ich eben beim anlegen auch schon rumcasten.
Oder wie würdest du das machen?

Jedenfalls tut das jetzt, ab und zu gibts maln NACK nachm write, aber 
das kann ja immermal vorkommen beim I2C wenn der Slave grade kein Bock 
hat zu Antworten.

[Jim M. (turboj)]

Mw E. schrieb:
> Erst durch das Casten wird das volatile, ist das struct volatile, so
> auch seine Inhalte.

Zuviele Casts. Kann man weglassen, wenn man das volatile in das Struct 
packt:

struct i2c {
  volatile unsigned int CR1;
  volatile unsigned int CR2;
  volatile unsigned int OAR1;
  volatile unsigned int OAR2;
  volatile unsigned int DR;
  volatile unsigned int SR1;
  volatile unsigned int SR2;
  volatile unsigned int CCR;
  volatile unsigned int TRISE;
};

Erst dann macht der Compiler bei "normalen" Zugriffen alles richtig. So 
machen das alle OEM Header die ich hier finde.

Ich würde die "unsigned int" dann noch durch uint32_t ersetzen.