SPI-Kommunikationsproblem zwischen MCU und RF beim SAMR30 - Liest immer 0 aus

[Jakob (joiksn)]

Hallo mikrocontroller-Community,

ich stehe derzeit vor einer herausfordernden Problematik mit dem 
SAMR30E18A Modul, insbesondere bei der SPI-Kommunikation zwischen der 
Mikrocontroller-Einheit (MCU) und dem RF-Teil. Unabhängig von der 
SPI-Operation oder dem Befehl, gibt jede Leseoperation vom SPI konstant 
den Wert 0 zurück. Dieses Problem ist ziemlich rätselhaft.

Hier sind die wichtigsten Details zu meiner Konfiguration und dem 
Problem:

-Das Problem besteht speziell in der SPI-Schnittstelle zwischen der 
Mikrocontroller-Einheit (MCU) und dem RF-Teil des SAMR30E18A.

-Dies ist ein universelles Problem bei allen SPI-Leseoperationen – sie 
geben alle unabhängig vom spezifischen Befehl oder der Operation 0 
zurück.

-Im Gegensatz dazu funktionieren ähnliche Operationen auf einem SAMR30 
Xplained Pro Board mit einem SAMR30G18A korrekt.

-Ich habe darauf geachtet, dass die SPI-Konfigurationseinstellungen, 
einschließlich Taktfrequenz, Datenmodus, Bitreihenfolge und 
Chip-Select-Handhabung, korrekt sind und den Spezifikationen des SAMR30 
entsprechen.

-Die Stromversorgung und Erdung für den SAMR30E18A wurden überprüft und 
liegen innerhalb der Betriebsparameter.

-Das Initialisierungsverfahren wurde gemäß den Richtlinien des 
Herstellers durchgeführt.

-Auch beim Ausführen von ASF (Atmel Software Framework) 
Beispielprojekten, die normalerweise zuverlässig sind, tritt dasselbe 
Problem des Auslesens von 0 bei meinem SAMR30E18A Setup auf.

Eine bedeutende Herausforderung bei der Adressierung dieses Problems ist 
die Unzugänglichkeit der internen SPI-Leitungen, da sie im SAMR30-Die 
eingebettet sind, was direkte Messungen oder Sondierungen unmöglich 
macht.

Ich würde mich sehr über Ratschläge oder Einblicke freuen, insbesondere 
von Personen, die Erfahrungen mit dem SAMR30E18A gesammelt haben. Gibt 
es spezielle Aspekte oder Überlegungen bei der Verwendung der 
SPI-Schnittstelle zwischen der MCU und dem RF-Teil des SAMR30E18A, die 
im Vergleich zum SAMR30G18A-Modell zu beachten sind? Über jegliche 
Vorschläge zu alternativen Fehlerbehebungsmethoden oder 
Diagnosetechniken, die in diesem speziellen Fall angewendet werden 
könnten, wäre ich sehr dankbar.

Vielen Dank im Voraus für jegliche Ratschläge oder Hilfestellungen.

[Peter (pittyj)]

Ich schließe immer ein Oszilloskop an. Dann kann man sehen, was wirklich 
auf dem Bus los ist.
Dann merkt man, das CS doch nicht richtig geht, oder der falsche 
SPI-Mode aktiviert ist, oder oder oder.
Kommt man da wirklich nicht ran?

[Jakob (joiksn)]

Peter schrieb:
> Ich schließe immer ein Oszilloskop an. Dann kann man sehen, was wirklich
> auf dem Bus los ist.
> Dann merkt man, das CS doch nicht richtig geht, oder der falsche
> SPI-Mode aktiviert ist, oder oder oder.
> Kommt man da wirklich nicht ran?

Danke für die Antwort. So würde ich das normalerweise auch machen, aber 
das ist ein Package, wo sich ein SAM L21 und ein AT86RF212B drin 
befinden. Die SPI-Lines werden auch nicht nach außen gerouted.

Mit dem Dev-Board von Microchip funktioniert auch der selbe Code, also 
würde ich darauf schließen, dass der AT86RF212B-Teil auf dem Eval-Board 
mit meinem Design defekt ist... was dann aber sehr komisch wäre mMn

[Peter D. (peda)]

Wird vorher am RF-Modul der Reset (PB15) gepulst?
Wenn man für MISO (PC19) den Pullup enabled und /SEL (PB31) auf high 
läßt, sollte FF gelesen werden.
Man könnte auch das SPI mit Pinwackeln zu Fuß probieren.

[Jakob (joiksn)]

Peter D. schrieb:
> Wird vorher am RF-Modul der Reset (PB15) gepulst?
> Wenn man für MISO (PC19) den Pullup enabled und /SEL (PB31) auf high
> läßt, sollte FF gelesen werden.
> Man könnte auch das SPI mit Pinwackeln zu Fuß probieren.

Der reset-Pin wird vorher gepulst. Wenn ich den /CS auf high lassen 
(pullup auf miso war immer aktiviert), dann lese ich bei beiden Boards 
0x0000 auf dem SPI Bus

Was meinst du mit Pinwackeln?

[Jakob (joiksn)]

Update:
Hab 2 weitere Boards erhalten, bei denen es einwandfrei funktioniert.
Also muss wohl der IC defekt sein.