Die STM32-SPI-Uhr wird nicht hoch im Leerlauf sein

Unter Verwendung des STM32F103RBT6-Chips (speziell Olimex STM32-H103-Board), Keil u5. Kommunikation mit dem Magnetsensor AS5311

Das SPI-Peripheriegerät wird nur im Master-Modus für unidirektionalen Empfang eingerichtet. CPHA = 1 und CPOL = 1. Der Clock-Pin ist als Push-Pull-Wechselfunktion eingestellt. Initialisierung von SPI ist unten:

  hspi1.Instance = SPI1;
  hspi1.Init.Mode = SPI_MODE_MASTER;
  hspi1.Init.Direction = SPI_DIRECTION_2LINES_RXONLY;
  hspi1.Init.DataSize = SPI_DATASIZE_8BIT;
  hspi1.Init.CLKPolarity = SPI_POLARITY_HIGH;
  hspi1.Init.CLKPhase = SPI_PHASE_2EDGE;
  hspi1.Init.NSS = SPI_NSS_SOFT;
  hspi1.Init.BaudRatePrescaler = SPI_BAUDRATEPRESCALER_256;
  hspi1.Init.FirstBit = SPI_FIRSTBIT_MSB;
  hspi1.Init.TIMode = SPI_TIMODE_DISABLED;
  hspi1.Init.CRCCalculation = SPI_CRCCALCULATION_DISABLED;
  hspi1.Init.CRCPolynomial = 10;
  HAL_SPI_Init(&hspi1);

Ich gebe dann eine Schleife mit folgendem Code einfach auf einen konstanten Empfangsmodus

while (1)
{
  HAL_GPIO_WritePin(GPIOA, GPIO_PIN_1, GPIO_PIN_RESET);
  HAL_SPI_Receive(&hspi1, (uint8_t *)Rx_Buffer, 3, HAL_MAX_DELAY);
  HAL_GPIO_WritePin(GPIOA, GPIO_PIN_1, GPIO_PIN_SET);
  HAL_Delay(1);
}

Ich habe die Polarität und Phase im Perihperhal Viewer überprüft und kann sehen, dass die Register sowohl für CPOL als auch für CPHA auf 1 gesetzt sind. Wenn ich jedoch einen Saleae-Logikanalysator verwende, kann ich sehen, dass die Uhr nach der Übertragung von Daten nicht hoch im Leerlauf ist.SALEAE Erfassung von SPI-Daten

In Bezug auf die Hardware ist die Uhr direkt ohne Pull-Up/Down-Widerstände verbunden.

Irgendwelche Ideen, warum die Uhr nicht hoch läuft?

Sieht so aus, als würde es im Leerlauf auf Hoch laufen, wenn es aktiviert ist.
@EugenSch. Wenn es aus der Funktion HAL_SPI_Recieve kommt, ist das SPI deaktiviert?
Ich spreche über das untere Signal, das einen Unterschied zu machen scheint (nicht sicher, da nicht genug davon gezeigt wird).
@EugenSch. die Signale setzen sich alle wie am Ende der Spuren gezeigt fort, dh Clock Low, Enable Low und MISO Low. bis die Verzögerung endet und ein neuer Empfang aktiviert ist
Womit ist dieses Signal verbunden (was treibt es an)? Ist das GPIOA, GPIO_PIN_1?
@EugenSch. Ja, es ist GPIOA, GPIO_PIN_1. Dies wirkt sich also überhaupt nicht auf die SPI-Uhr aus
Wer ist der Sklave? Upd: Macht nichts, ich sehe es
Zur ersten Kante wechseln. Ö
Hmm, ich glaube, ich hatte das gleiche Problem, der Pin scheint in den Hochimpedanzmodus zu wechseln, nachdem das Peripheriegerät die Transaktion abgeschlossen hat. Ich habe den Pull-up auf dem Pin aktiviert. Vielleicht finden einige weitere Untersuchungen eine bessere Lösung, aber ich musste weitermachen.
@ PeterJ_01 Das Slave-Gerät benötigt eine zweite Kante, ändert sich jedoch, um zu sehen, ob es Auswirkungen hat

Antworten (3)

Ich war auf ein ähnliches Problem gestoßen und nach Tagen der Recherche und Fehlerbehebung bemerkte ich einen Trend, dass jeder, der dieses Problem hatte, sein SPI nur als RX konfigurierte. Als ich mein SPI in den TX RX-Modus änderte, wurde das Problem auf magische Weise gelöst. Ich bin mir nicht sicher, was dies verursachen könnte, aber es scheint ein Fehler auf der Seite von ST zu sein, entweder als Teil der HAL-Bibliothek oder als Teil des Geräts selbst. So oder so, jetzt habe ich nur einen unbenutzten MOSI-Pin konfiguriert, aber das SCK-Leerlaufproblem wurde gelöst. Hoffe, das hilft jemandem etwas Zeit und Kopfschmerzen zu ersparen!

Pin geht nach N Taktimpulsen in den Floating-Zustand (hohe Impedanz, hi-Z). Das Problem wurde durch die Konfiguration des Clock-Pins auf internen Pull-up behoben.

Ich hatte das gleiche Problem. Meine Lösung bestand darin, direkt nach der Konfiguration der SPI-Schnittstelle ein Dummy-Byte (ohne CS) zu senden (zu übertragen).

Die STM32-SPI-Uhr wird nicht hoch im Leerlauf sein
AntwortenHierDatenschutz-Bestimmungen1y, 1v