STM32L476 - UART Frame Error

[Steve K. (sktron)]

Tach auch,

mit dem STM32L476 / nucleo-L476RG board habe ich einen UART mit nutzung 
der HAL zunächst mal nur auf senden konfiguriert. (bzw USART3 im UART 
modus, mit UART4 habe ich es aber auch probiert)
Das funktionierte auch soweit, via FTDI modul kommen die daten im 
terminal auf dem PC an.
Das war im Blocking mode, also mit HAL_UART_Transmit(...).

Wenn ich jetzt auch empfangen möchte, und das ganze interruptbasiert, 
und daher auch transmits mit HAL_UART_Transmit_IT(...) starte, habe ich 
ein merkwürdiges phänomen:
Obwohl nur transmit gestartet wurde, lande ich im 
HAL_UART_ErrorCallback, und der ErrorCode ist immer 4, also Frame Error.
Ich setze den fehler dort zurück:
  if (huart->ErrorCode & HAL_UART_ERROR_FE)
  {
    __HAL_UART_CLEAR_FLAG( huart, UART_CLEAR_FEF );
  }
aber er kommt immer wieder.

Und das, obwohl ich den RX pin mit ner klemme auf VCC gezogen habe! Da 
kann also kein falsches signal sein.
Ich habe auch getestet, ob der pin an der stiftleiste mit dem richtigen 
pin der MCU verbunden ist, und den RX pin (PC11) mal als normalen GPIO 
INPUT ohne AlternateFunction konfiguriert, außen am pin zwischen VCC und 
GND umgeschaltet - dies kann in der MCU durch lesen des pins auch 
verifiziert werden.
Für den UART betrieb ist der pin ansonsten auf INPUT und mit der 
alternate function für den entspr. U(S)ART konfiguriert, also zB 
AF7_USART3 oder AF8_UART4.

Frame Error heißt doch eigentlich, dass ein einkommendes signal einen 
falschen takt hat... Oder laut manual, dass ein "break" zeichen 
empfangen wurde, was auch immer das bedeutet - aber mit RX fest auf VCC 
dürfte das kaum passieren.
Für mich macht das keinen sinn.

Weiß jemand, woran das liegen könnte?

[Georg G. (df2au)]

Leg den Eingang mal auf GND.

Zu "was ist Break" kannst du Google bemühen.

[Steve K. (sktron)]

GND hatte ich auch schon, das änderte nichts

[Steve K. (sktron)]

Update:

ich hab mal das UART beispiel von ST für's nucleo L476RG board genommen, 
das zwischen 2 boards hin und her sendet. Damit hatte ich schon mal 
keinen frame error mehr, trotz identischem* hardware aufbaus.
Wie ist das erklärbar?

Aber da kam er nicht zur code zeile wo er die daten zurücksendet und 
prüft.
Da ich mich drüber wunderte, dass bei der von mir vom CubeMX 
ausgespuckten HAL dateien manche sachen nicht definiert waren, wie 
GPIO_SPEED_VERY_HIGH, und ich einen versionskonflikt vermutete, lud ich 
die aktuelle CubeL4.zip von der ST seite und ersetzte den CMSIS + HAL 
kram in meinem projekt mit dem "neuen" (?)
Nun geht alles...

----
* den RX pin auf VCC bzw auf masse, wie im original post beschrieben, 
hatte ich erst, nachdem ich eigentlich die beiden boards verbunden hatte 
und beide entspr. für das gleiche szenario programmiert

[./. (Gast)]

Ich hab meine USARTs auf Registerebene programmiert, und
oh Wunder, es hat auf Anhieb funktioniert.

Datenblattleser wissen mehr.

[Steve K. (sktron)]

Ich bin auch das datenblatt bzw eher reference manual durchgegangen und 
alle relevant scheinenden register / bits im debugger geprüft, leider 
half das auch nicht.
Vermutlich irgendwas unscheinbares, das wichtiger ist, als es aussah...

Wobei das jetzt ein wenig modifiziertes, isoliertes ST beispiel ist, ist 
auhc möglich, dass der rest der firmware, die vorher um mein UART RX 
bemühen herum war, da irgendwas kaputt macht,
das wird sich herausstellen, wenn ich das funktionierende beispiel 
rückverpflanze ;-)