RFID RC522 mit STM32F769I-Erkennung

Ich versuche, mit diesem Code mit dem rc522-Chip zu kommunizieren . Ich habe nur die SPI-Aufrufe geändert, um die HAL-Bibliotheken zu verwenden, und SPI mit HAL-Bibliotheken initialisiert. Alle anderen Funktionen bleiben erhalten. Das Bild unten ist das, was ich mit meinem Logikanalysator aufgenommen habe, und ich habe wirklich keine Ahnung, was ich falsch mache. Für mein neues Auge sieht meine SPI-Kommunikation in Ordnung aus. Der Chip gibt jedoch nicht wirklich etwas zurück und ich bekomme jedes Mal 0xFF (ich habe das auch mit meinem Logikanalysator erfasst, während rc522 mit meinem STM32F7Discovery verbunden war).

Geben Sie hier die Bildbeschreibung ein

Hat jemand eine Idee, warum mein Chip überhaupt nicht reagiert?

Ich initialisiere mein SPI mit:

    /* SPI SCK GPIO pin configuration  */
GPIO_InitStruct.Pin       = SPIx_SCK_PIN;
GPIO_InitStruct.Mode      = GPIO_MODE_AF_PP;
GPIO_InitStruct.Pull      = GPIO_PULLUP;
GPIO_InitStruct.Speed     = GPIO_SPEED_HIGH;
GPIO_InitStruct.Alternate = SPIx_SCK_AF;
HAL_GPIO_Init(SPIx_SCK_GPIO_PORT, &GPIO_InitStruct);

/* SPI MISO GPIO pin configuration; MISO line should be floating */
GPIO_InitStruct.Pull      = GPIO_NOPULL;
GPIO_InitStruct.Pin = SPIx_MISO_PIN;
GPIO_InitStruct.Alternate = SPIx_MISO_AF;
HAL_GPIO_Init(SPIx_MISO_GPIO_PORT, &GPIO_InitStruct);

/* SPI MOSI GPIO pin configuration  */
GPIO_InitStruct.Pull      = GPIO_PULLUP;
GPIO_InitStruct.Pin = SPIx_MOSI_PIN;
GPIO_InitStruct.Alternate = SPIx_MOSI_AF;
HAL_GPIO_Init(SPIx_MOSI_GPIO_PORT, &GPIO_InitStruct);

/* SPI CS GPIO pin configuration  */
GPIO_InitStruct1.Pin = SPIx_CS_PIN;
GPIO_InitStruct1.Mode = GPIO_MODE_OUTPUT_PP;
GPIO_InitStruct1.Speed = GPIO_SPEED_HIGH;
GPIO_InitStruct1.Pull = GPIO_PULLUP;
HAL_GPIO_Init(SPIx_CS_GPIO_PORT, &GPIO_InitStruct1);

SPIx_CLK_ENABLE();

SpiHandle.Instance               = SPIx;
SpiHandle.Init.BaudRatePrescaler = SPI_BAUDRATEPRESCALER_32;
SpiHandle.Init.Direction         = SPI_DIRECTION_2LINES;
SpiHandle.Init.CLKPhase          = SPI_PHASE_1EDGE;
SpiHandle.Init.CLKPolarity       = SPI_POLARITY_HIGH;
SpiHandle.Init.DataSize          = SPI_DATASIZE_8BIT;
SpiHandle.Init.FirstBit          = SPI_FIRSTBIT_MSB;
SpiHandle.Init.TIMode            = SPI_TIMODE_DISABLE;
SpiHandle.Init.CRCCalculation    = SPI_CRCCALCULATION_DISABLE;
SpiHandle.Init.NSS               = SPI_NSS_SOFT;
SpiHandle.Init.Mode              = SPI_MODE_MASTER;

Ich verbinde den Reset-Pin meines Boards direkt mit dem RFID-RC522-Reset-Pin.

Ich habe den Chip auch mit der Bibliothek von Miguel Balboa für Arduino ausprobiert und es funktioniert dort einwandfrei.

Nachdem ich die Reset-Taste auf meinem Board gedrückt habe, werden die ersten beiden Werte nicht einmal von der Software des Analysators dekodiert. Wenn ich mir anschaue, was die Bibliothek zum Zurücksetzen senden soll, ist 0x01<<1, also 0x02 als reg_command-Adresse, dann 0x0f als pcd-Reset-Befehl. Warum sollte es anders sein?

Hier ist ein Bild, wie die Kommunikation direkt nach einem Reset aussieht:

Geben Sie hier die Bildbeschreibung ein

Wie Sie sehen können, geht meine Chipauswahl während des Zurücksetzens auf Low und ist immer noch Low, wenn die Kommunikation beginnt, obwohl ich einen Pullup darauf gelegt habe.

Auch dieser Absatz aus dem Datenblatt lässt mich glauben, dass ich meine SPI CPOL/CPHA-Werte falsch verstanden haben könnte, da die Daten anscheinend während der fallenden Taktflanke stabil sind (ich dachte, das ist die Einstellung von SPI_PHASE_1EDGE):

Datenbytes sowohl auf den MOSI- als auch auf den MISO-Leitungen werden zuerst mit dem MSB gesendet. Daten sowohl auf den MOSI- als auch auf den MISO-Leitungen müssen an der steigenden Flanke des Takts stabil sein und können an der fallenden Flanke geändert werden. Daten werden vom MFRC522 an der fallenden Taktflanke bereitgestellt und sind während der steigenden Taktflanke stabil.

Auch aus diesem Absatz, der der einzige ist, der diese Werte beschreibt, kann ich nicht entziffern, was der Basiswert der Uhr sein sollte. Hoch oder tief?

Sie konfigurieren auch an SPIx_NSS_PINund an . SPIx_CS_PINWelcher ist Ihr echter Chip-Select-Pin?
@Bence Kaulics SPIx_CS_PIN. Sie haben Recht, das NSS macht nicht viel, es wird nur initialisiert. Habe es entfernt.

Antworten (1)

Ihr Verdacht scheint richtig zu sein und Ihre SPI-Uhreinstellungen sind falsch. Im Bild des Logikanalysators ist zu beobachten, dass sich die Daten bei steigender Flanke ändern und bei fallender Flanke stabil sind.

Geben Sie hier die Bildbeschreibung ein

Wenn Sie das SPI-Timing-Diagramm im Datenblatt des RC522 überprüfen . Sie können sehen, dass die Uhr vor der Kommunikation LOW ist, die Daten bei der steigenden Flanke abgetastet werden und sich die Daten bei der fallenden Flanke ändern.

Geben Sie hier die Bildbeschreibung ein

Jetzt hat der STM32 die CPOL- und CPHA-Einstellungen, von denen Sie angenommen haben, dass sie falsch sind. Die Beschreibung für diese aus dem STM32F7xx-Referenzhandbuch :

Bit1 CPOL: Taktpolarität

0: CK auf 0 im Leerlauf

1: CK auf 1 im Leerlauf

Bit 0 CPHA: Taktphase

0: Der erste Taktübergang ist die erste Datenerfassungsflanke

1: Der zweite Taktübergang ist die erste Datenerfassungsflanke

Für Ihre CPHA- Einstellung: SpiHandle.Init.CLKPhase = SPI_PHASE_1EDGE;ist richtig, im Zeitdiagramm werden die Daten beim ersten Taktübergang abgetastet. Aber es sollte eine steigende Flanke sein und keine fallende.

Für CPOL ist Ihre Einstellung Leerlauf HIGH, während sie im Zeitdiagramm Leerlauf LOW ist. Wenn Sie beobachten, dass, wenn Ihr Taktsignal negiert würde, der erste Taktübergang eine steigende Flanke wäre, während die Daten stabil sind und sich die Daten bei einer fallenden Flanke ändern würden.

Alles in allem würde ich versuchen, diese Zeile zu ändern:

SpiHandle.Init.CLKPolarity       = SPI_POLARITY_HIGH;

Zu:

SpiHandle.Init.CLKPolarity       = SPI_POLARITY_LOW;

Sie können auch mit Versuch und Irrtum vorgehen, da Sie maximal 4 Takttypen und den Logikanalysator zum Überprüfen der Signale haben.

Das war hilfreich, danke! Es gibt jedoch immer noch einen Fehler im Protokoll, der vom rc522 gemeldet wird. Ich habe den ursprünglichen Beitrag mit weiteren Informationen aktualisiert.
Egal, es war ein Fehler in meinen Modifikationen der Bibliothek. Ich kann jetzt problemlos mit dem Chip kommunizieren.
@Nirri Ich bin froh, das hier zu haben.
Als Faustregel gilt jedoch: Wann immer SPI ausfällt oder sich mysteriös verhält, überprüfen Sie immer CPHA und CPOL. Das ist also trotzdem ein guter Rat.
Sie haben das bereits perfekt behandelt, ich wollte nur hinzufügen, dass ich dieses Diagramm sehr hilfreich finde, wenn ich CPOL und CK konfiguriere