Hi,
ich habe hier ein Problem mit einem ATSAMD51G. Ich versuche per
SERCOM-SPI Daten zu empfangen. Allerdings wird das RXC-Flag nie gesetzt,
sprich es landen keine Daten im Eingangsregister.
Was ich bereits überprüft habe:
- Pin-Multiplexing scheint zu passen
- Eingangssignale mit dem Oszi üperprüft, sind OK
- Polarität für CLK- und /SS-Signale sollten passen, bzw. ich habe alle
Varianten mit CPOL/CPHA/SSDE durchprobiert
- Bei der Clock-Konfiguration des SERCOM-Moduls bin ich mir halbsicher,
(Core hat 60 MHz, sollte aber egal sein, da CLK ja von der Gegenstelle
kommt?)
Wo ich mir unsicher bin: ich habe das DATA32B-Bit in CTRLA gesetzt, weil
ich längere Frames empfangen will. Allerdings hat mein SPI-Signal jetzt
keine 32 Bit, sondern 22. Könnte das ein Problem sein, sprich erwartet
SERCOM in dem Fall genau 32 Bits?
Oder sollte es damit umgehen können, wenn /SS nach 22 Bits auf High geht
und dann halt einfach diese 22 Bits nach DATA übernehmen und die oberen
10 Bit auf 0 lassen?
Ich bin für jeden Hinweis dankbar!
Narvik schrieb:> einem ATSAMD51G. Ich versuche per SERCOM-SPI Daten zu empfangen.
Wer ist der SPI-Master?
> Allerdings wird das RXC-Flag nie gesetzt, sprich es landen keine Daten> im Eingangsregister.
Falls der SAM Master ist, dann ist dir prinzipiell schon klar, dass du,
wenn als Master was empfangen willst, genau so viele Bits senden
musst?
Der SAM ist der Slave, CLK kommt von der Gegenstelle. Er würde dabei
übrigens nur empfangen, die Senderichtung wird nicht verwendet.
Ist das eventuell das Problem, sprich muss ich Ihn trotzdem mit
Dummy-Sendedaten füttern oder die Senderichtung irgendwie explizit
abschalten?
Narvik schrieb:> Wo ich mir unsicher bin: ich habe das DATA32B-Bit in CTRLA gesetzt, weil> ich längere Frames empfangen will. Allerdings hat mein SPI-Signal jetzt> keine 32 Bit, sondern 22. Könnte das ein Problem sein, sprich erwartet> SERCOM in dem Fall genau 32 Bits?
Du meinst, ob der SAM genau 32 Bits erwartet?
Gut möglich, dass da ein Zähler drin ist, der erst bei 32 Bits "fertig"
meldet, und der SS# da gar nicht mitmischt.
> Oder sollte es damit umgehen können, wenn /SS nach 22 Bits auf High geht> und dann halt einfach diese 22 Bits nach DATA übernehmen und die oberen> 10 Bit auf 0 lassen?
Probiers aus: setze einen PinChange Interrupt auf den SS# und sieh nach,
was nach einer steigenden Flanke im Datenregister ist.
Lothar M. schrieb:>> Wo ich mir unsicher bin: ich habe das DATA32B-Bit in CTRLA gesetzt, weil>> ich längere Frames empfangen will. Allerdings hat mein SPI-Signal jetzt>> keine 32 Bit, sondern 22. Könnte das ein Problem sein, sprich erwartet>> SERCOM in dem Fall genau 32 Bits?> Du meinst, ob der SAM genau 32 Bits erwartet?> Gut möglich, dass da ein Zähler drin ist, der erst bei 32 Bits "fertig"> meldet, und der SS# da gar nicht mitmischt.
OK, aber wie kann ich dann 22 Bits empfangen? Bitbanging geht nicht, da
ist der ATSAM selbst mit 120 MHz zu langsam.
>> Oder sollte es damit umgehen können, wenn /SS nach 22 Bits auf High geht>> und dann halt einfach diese 22 Bits nach DATA übernehmen und die oberen>> 10 Bit auf 0 lassen?> Probiers aus: setze einen PinChange Interrupt auf den SS# und sieh nach,> was nach einer steigenden Flanke im Datenregister ist.
Das kann ich dir sagen: da ist nix drin.
Narvik schrieb:> Das kann ich dir sagen: da ist nix drin.
Ist auch nach 2 Telegrammen nix drin? Und kommt auch nix an, wenn du nur
16 Bits empfangen willst?
Dann ist das Ding noch nicht richtig als Slave konfiguriert.
Lothar M. schrieb:> Ist auch nach 2 Telegrammen nix drin?
Nö.
> Und kommt auch nix an, wenn du nur> 16 Bits empfangen willst?
Ich habe das DATA32B-Bit mal probehalber rausgenommen, das macht keinen
Unterschied.
> Dann ist das Ding noch nicht richtig als Slave konfiguriert.
Die Konfiguration habe ich per Atmel Start gemacht, so weit ich das
beurteilen kann, sieht der so erzeugt Code gut aus. Lediglich mit dem
internen Clock für das SERCOM-Modul bin ich mir unsicher, ich habe da
jetzt halt einfach mal 60 Mhz verwendet...
Naja, Glaskugel defekt und so, zeig doch mal wenigstens wie Du welche
SERCOM Einheit für welche Pins zu konfiguieren versuchst.
Für ein so eher exotisches Problem (gibt hier nicht viele die ATSAM
nutzen) wäre ein minimales Test-Projekt hilfreich - eines das auch baut.
Wobei ich den Hinweis auf Start eher beunruhigend finde.
Rudolph R. schrieb:> Naja, Glaskugel defekt und so
Ja...meine Frage war ja eigentlich auch eher, ob bei gesetzten
DATA32B-Flag weniger als 32 Bits empfangen werden können und was es mit
dem Core-Clock auf sich hat...
Narvik schrieb:> Ja...meine Frage war ja eigentlich auch eher, ob bei gesetzten> DATA32B-Flag weniger als 32 Bits empfangen werden können
When SS is pulled low and SCK is running, the slave will sample and
shift out data according to the
Transaction mode set. When the content of TxDATA has been loaded into
the Shift register,
INTFLAG.DRE will be set, and new data can be written to DATA.
When the master pulls the SS line high, the transaction is done and the
Transmit Complete Interrupt flag
in the Interrupt Flag Status and Clear register (INTFLAG.TXC) will be
set.
Das interpretiere ich so, dass die Daten auf jeden Fall eingetaktet
werden.
Aber im Moment funktioniert das ja nicht mal mit 8 Bit bei Dir.
Da könnte noch sonst was falsch sein, Muxer falsch benutzt oder Takt
nicht aktiviert, oder oder oder.
> und was es mit dem Core-Clock auf sich hat...
In SPI slave operation (CTRLA.MODE is 0x2), the clock is provided by an
external master on the SCK
pin. This clock is used to clock the SPI Shift register
Und das hier:
• Slave Operation:
– Serial clock speed, fSCK=1/tSSCK(1)
Und da wird es sehr schwammig.
tSSK ist 2 * (tSIS + tMaster_OUT) für den Empfang
tSIS ist mit min. 7,5ns ab 2,7V angegeben.
tMaster_OUT gibt es nur als Fußnote und ist tEXT_MOV + tLINE_DELAY
Wenn man für tMASTER_OUT mal Null ansetzt, ergibt sich das der externe
Takt kleiner sein muss als 66MHz.
Wenn man noch mal 5ns für tMASTER_OUT ansetzt sind das 40MHz.
Zusätzlich sind da noch tSSS und tSSH interessant.
tSSS vor allem da es von tAPBC abhängt.
Eigentlich wird die SERCOM im Slave Modus von Aussen getaktet.
Man muss aber trotzdem wie im Master-Betrieb den Takt über
MCLK->APBDMASK aktivieren und über das zu der SERCOM gehörigen
GCLK->PCHCTRL Register eine Taktquelle auswählen und einschalten.
Man muss nur das BAUD Register nicht beschreiben.
So zum Beispiel:
MCLK->APBDMASK.bit.SERCOM5_ = 1;
GCLK->PCHCTRL[35].reg = GCLK_PCHCTRL_GEN_GCLK1 | GCLK_PCHCTRL_CHEN;
Hier ich habe gerade noch was nettes dazu gefunden:
https://microchipdeveloper.com/32arm:samc21-sercom-spi-slave-configuration
Die SERCOM von den SAMC2x sind komplett identisch mit denen von den
SAMx5x.
Ich benutze die zwar selber nur im Master Betrieb, aber sowohl den
ATSAMC21E18A als auch den ATSAME51J19A.
Die SERCOM von den SAMC2x vertragen allerdings nur 48MHz, während die
von den SAMx5x mit 100MHz angegeben sind.
(Ups, mein Code läuft gerade mit den 120MHz von GCLK0, muss ich wohl
ändern...)
