STM32F466: kein CLK/DATA an SPI1

[Willi W. (willi_w571)]

Hi,

ich habe hier einen STM32F466, für den ich den Basiscode per CubeMX 
erzeugen lasse. Dort ist SPI1 als "transmit only" mit einem Prescaler 
von 4 und damit einer Baudrate von 22,5 MHz sowie "Hardware NSS Signal" 
als disabled konfiguriert. Mein Problem: ich sehe weder den Clock des 
SPI noch die Daten, wenn ich das DR-Register beschreibe. Die 
Inizialisierung ist generierter Code:

    MX_SPI1_Init();

So weit ich das sehe, wird da alles initialisiert, inklusive des 
korrekten Pin-Mappings.

Was ich nicht sehen kann, ist die aktivierung des SPI-Moduls, die hole 
ich selber nach:

    if ((hspi1.Instance->CR1 & SPI_CR1_SPE) != SPI_CR1_SPE)
    {
       /* Enable SPI peripheral */
       __HAL_SPI_ENABLE(&hspi1);
    }

Das Senden der Daten ist simpel gehalten, es wird erst überprüft, ob der 
Sendebuffer leer ist, dann wird der nächste 8-Bit-Wert geschrieben:

    while ((hspi1.Instance->SR & SPI_FLAG_TXE)==0);
    *((__IO uint8_t *)hspi1.Instance->DR)=((vx & 0xFF0000)>>16);

Allein, an PA5 (CLK) und PA7 (DATA) ist nichts zu sehen.

Die Clocks ABP1 und ABP2 sind gesetzt und aktiv, sollte also auch 
passen. Würde mit den Clocks was nicht stimmen, sollte SPI_FLAG_TXE ja 
auch nie gesetzt werden und der code würde auf ewig darauf warten, dass 
der Sendebuffer leer wird.

Woran könnte es noch liegen, dass am Ausgang nichts zu sehen ist?

Danke!

[Wastl (hartundweichware)]

Nachdem es in der Source <stm32f4xx_hal_spi.c> kein explizites
Schreiben von einzelnen Bytes (weder als Makro noch als Funktion)
gibt, wird es dringend empfehlensert sein die vorhandenen
Funktionen zu nutzen (in diesem Fall dann <HAL_SPI_Transmit(...)>.
Wenn du dir die Funktionen anschaust gibt es da eine Menge
von zusätzlichen Code der ggf. abgearbeitet wird bzw abgearbeitet
werden muss. Schon allein wegen dieser Unübersichtlichkeit benutze
ich grundsätzlich die LL-Libraries mit denen ich ähnlich der Bare-
Metal-Programmierung noch wunderbar auf die Register zugreifen
kann und damit genau weiss was ich mache (oder unterlasse). Jeden-
falls ist die gemischte Verwendung von HAL und Direktzugriffen
auf die Register eine schlechte Idee da man überhaupt nicht
mehr die Übersicht hat was passiert.

[Andreas B. (abm)]

Zwischen dem Glauben, alles sei korrekt initialisiert (inkl. Clocks) 
und dem Wissen, alles ist korrekt initialisiert, besteht ein wichtiger 
Unterschied. Im Zweifel muss man halt alle relevanten Bits in den ganzen 
Registers händisch gegen RM vergleichen. Also das, was in den Registern 
tatsächlich drin steht (mit Debugger auslesen!), und nicht, was man 
meint, hineingeschrieben zu haben.

[Wastl (hartundweichware)]

Andreas B. schrieb:
> Zwischen dem Glauben, alles sei korrekt initialisiert (inkl. Clocks)
> und dem Wissen, alles ist korrekt initialisiert, besteht ein wichtiger
> Unterschied.

Dem HAL Code würde ich schon vertrauen zudem es eine (F4-)
Architektur betrifft die es schon lang gibt. Aber - ich hatte
es schon angedeuted - muss man sich dann schon komplett an
die Regeln der HAL-Programmierung halten und nicht auf die
Register direkt zugreifen. Soviel ich abschätze (ich schaue
jetzt nicht nach da ich keine HAL-Implementierung habe) wird
man Interrupts abarbeiten müssen die sich in einem oder
mehreren Callbacks bemerkbar machen. Die Callbacks sind
vermutlich bereits Teil der HAL-Initialisierung für das SPI,
existieren also schon aber müssen noch mit "Leben" erfüllt
werden.

[Peter (pittyj)]

Ich benutze auf den STMs nur den HAL-Code und keine direkten 
Registerzugriffe.
Das funktioniert für I2C, SPI, I2S...
Die Jungs von STM, die die sich auskennen, haben das für mich 
programmiert.

Und wenn es 5% langsamer ist, was solls. Damit kann ich leben.
Bevor ich mich aber tagelang an das Debuggen auf der Registerebene 
begebe .... da kann ich mit der Zeit was besseres anfangen.