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?
Leg den Eingang mal auf GND. Zu "was ist Break" kannst du Google bemühen.
GND hatte ich auch schon, das änderte nichts
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
#4333301
Ich hab meine USARTs auf Registerebene programmiert, und oh Wunder, es hat auf Anhieb funktioniert. Datenblattleser wissen mehr.
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 ;-)