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...)
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.