STM32: SPI1 liefert 0, Chip kaputt?

[Bernd (Gast)]

Ich habe hier zwei augenscheinlich identische Boards mit einem 
STM32F407. An diese Boards kann ich einen SPI-Slave anstecken.
Bei Board A funktioniert alles wie erwartet und ich kann mit dem 
SPI-Slave kommunizieren. Bei Board B erhalte ich nur 0 zurück, obwohl 
der Code identisch ist.
Mit dem Oszilloskop habe ich direkt am Chip gemessen und sehe auf MISO 
das Signal vom Slave.

Nun hatte ich einen defekten SPI-MISO-Pin in Verdacht. Daher habe ich 
separate Testprogramme geschrieben. Das Ergebnis: der Pin funktioniert 
als Input und der Pin funktioniert auch als Output korrekt. Er will nur 
nicht, wenn er als MISO für die SPI im Alternate-Funktion-Modus 
konfiguriert ist.

Auf dem zweiten System funktionieren alle Programme wie erwartet.
/CS, CLK, MOSI und MISO sehen bei beiden Systemen auf dem Oszilloskop 
identisch aus.

So langsam gehen mir die Ideen aus, wo der Fehler liegen könnte.
Vielleicht habt ihr ja noch Vorschläge, was ich prüfen/testen/ändern 
könnte.

[asd (Gast)]

Du könntest auf dem anderen Board testen ob der Portpin für MISO geht 
wenn man ihn als einfachen Digital-In verwendet. Wenn das auch nicht 
geht ist vielleicht wirklich das Silizium kaputt.

[Marc X. (marc_x)]

Das die Endstufe in Ordnung ist, bedeutet nicht, dass der Multiplexer 
welche die Schnittstelle auf den Pin mappt in Ordnung ist.

Ich kenne den STM32F407 nicht. Ich gehe mal davon aus, dass sich SPI1 
auch auf andere Pins legen lässt, probiere das mal aus.

[A. B. (Gast)]

Aufdruck der beiden MCUs (Foto)? Chip-ID und Revision (unter 
0xE0042000)?

[Gehirn geeicht (Gast)]

Es klingt so, als ob es sich um ein Problem mit der Konfiguration der 
Alternate-Funktion für den MISO-Pin handelt. Da es auf dem ersten Board 
nicht funktioniert und auf dem zweiten Board funktioniert, obwohl der 
Code identisch ist, sollten Sie sicherstellen, dass die 
Alternate-Funktions-Register für den MISO-Pin auf beiden Boards korrekt 
konfiguriert sind. Es könnte auch sein, dass die Hardware des ersten 
Boards beschädigt ist und daher nicht richtig funktioniert. Es wäre 
ratsam, die Hardware des ersten Boards gründlich zu überprüfen und 
eventuell auszutauschen.

[Bernd (Gast)]

Vielen Dank an alle für eure Hinweise!

asd schrieb:
> Du könntest auf dem anderen Board testen ob der Portpin für MISO
> geht
> wenn man ihn als einfachen Digital-In verwendet.
Das hat mich ja so verwundet. Als Input geht der Pin. Als Output auch. 
Nur als AF macht er Späne.


Marc X. schrieb:
> Ich gehe mal davon aus, dass sich SPI1
> auch auf andere Pins legen lässt, probiere das mal aus.
Das hatte ich getestet, das ging auch nicht. Ich bin mir aber nicht 
sicher, ob es bei der alternativen Belegung auf diesem Board noch 
Nebenwirkungen gibt.


A. B. schrieb:
> Aufdruck der beiden MCUs (Foto)?
Der Aufdruck ist auf beiden Chips identisch:

STM32F407
VGT7 4
7B746 9R
PHL 7B 815

(kann Fehler enthalten, die Lasergravur ist recht schwer zu erkennen...)

> Chip-ID und Revision (unter 0xE0042000)?
Die Chip-ID ist auch bei beiden identisch (und m.E. plausibel):

DBGMCU_REVID: 0x1007
DBGMCU_DEVID: 0x0413

Die Chips stammen auch von einem namhaften Distributor und nicht von 
einem China-Broker.


Gehirn geeicht schrieb:
> obwohl der
> Code identisch ist, sollten Sie sicherstellen, dass die
> Alternate-Funktions-Register für den MISO-Pin auf beiden Boards korrekt
> konfiguriert sind.
Das werde ich evtl. noch untersuchen. Mit dem gdb-server hat man ja die 
Möglichkeit im laufenden System die Register auszulesen.


Eine Idee hatte ich doch noch:
Ich habe eine Liste mit allen Pins erstellt und dann die Spannungen von 
beiden Systemen aufgenommen. Dort gibt es einige Unterschiede. Jetzt 
werde ich erstmal untersuchen, wo diese Diskrepanzen herkommen. 
Möglicherweise sind die Boards doch nicht so identisch, wie ich das 
gerne hätte.
Ich werde berichten.

[Bernd (Gast)]

Bernd schrieb:
> Ich werde berichten.
Nachdem sich die vermeintlichen Unterschiede als Fehler bei der Messung 
herausgestellt haben (die Messpitze hatte gelegentlich keinen Kontakt), 
habe ich den Chip getauscht und nun geht die SPI wie erwartet.

Dafür funktioniert nun die Debugausgabe über ITM_SendChar() nicht mehr 
:-/
Naja, irgendwas ist ja immer...