STM32 USART4 funktioniert nicht

Welcher Chip ist es denn? Gibt ein paar mehr STM32.


Sicher dass dein USART kein UART ist? Beim ersten schellen Suchen eines 
Datenblattes war dem nämlich so. Also ggf. nicht nur das RefMan in die 
Hand nehmen.

Chip: STM32L071RBTx

CubeMX betitelt diese Pins als USART Pins. Kann CubeMX sich dort 
täuschen? Ich bin davon ausgegangen, dass die Software weiß was Sie tut.

Danke!

pegel schrieb:
> Funktioniert denn das FPM am USB-Seriell Wandler?

Das habe ich noch nicht getestet. Ein Bekannter nutzt dasselbe FPM, nur 
mit einem Atmel MC, daran angeschlossen funktioniert das FPM super. Also 
ich habe meins auch mal an seinem MC gehabt, von daher funktioniert das 
FPM definitiv. Daher auch der Gedanke daran, dass etwas am USART4 nicht 
stimmt.

So, habe es jetzt ausprobiert. Der MC schickt weder etwas raus, noch 
reagiert er auf empfangenes. Ich habe erst den Schleifentest gemacht und 
anschließend mit LEDs und einem UART->USB-Kabel eine Kommuniaktion mit 
dem PC hergestellt. Der PC sendet (LED blinkt) und der MC empfängt 
nicht. Der MC sendet und gibt ein HAL_OK zurück, der PC empfängt nicht, 
die LED bleibt aus.

ioc s. Anhang.

Nutze dementsprechend die Pins PA9/10. Habe es mal mit USART1 jetzt 
ausprobiert, funktioniert komischerweise jetzt auch nicht.


static void MX_USART1_UART_Init(void)
{

    __USART1_CLK_ENABLE();
  /* USER CODE BEGIN USART1_Init 0 */

  /* USER CODE END USART1_Init 0 */

  /* USER CODE BEGIN USART1_Init 1 */

  /* USER CODE END USART1_Init 1 */
  huart1.Instance = USART1;
  huart1.Init.BaudRate = 9600;
  huart1.Init.WordLength = UART_WORDLENGTH_8B;
  huart1.Init.StopBits = UART_STOPBITS_1;
  huart1.Init.Parity = UART_PARITY_NONE;
  huart1.Init.Mode = UART_MODE_TX_RX;
  huart1.Init.HwFlowCtl = UART_HWCONTROL_NONE;
  huart1.Init.OverSampling = UART_OVERSAMPLING_16;
  huart1.Init.OneBitSampling = UART_ONE_BIT_SAMPLE_DISABLE;
  huart1.AdvancedInit.AdvFeatureInit = UART_ADVFEATURE_NO_INIT;
  if (HAL_UART_Init(&huart1) != HAL_OK)
  {
    Error_Handler();
  }
  /* USER CODE BEGIN USART1_Init 2 */

  /* USER CODE END USART1_Init 2 */

}








static void MX_GPIO_Init(void)
{
  GPIO_InitTypeDef GPIO_InitStruct = {0};

  /* GPIO Ports Clock Enable */
  __HAL_RCC_GPIOA_CLK_ENABLE();

  /*Configure GPIO pins : PA9 PA10 */
  GPIO_InitStruct.Pin = GPIO_PIN_9;
  GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
  GPIO_InitStruct.Pull = GPIO_NOPULL;
  GPIO_InitStruct.Speed = GPIO_SPEED_HIGH;
  GPIO_InitStruct.Alternate = GPIO_AF5_USART1;
  HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);

  GPIO_InitStruct.Pin = GPIO_PIN_10;
    GPIO_InitStruct.Mode = GPIO_MODE_AF_OD;
    HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);
}

pegel schrieb:
> Ich verstehe auch nicht ganz warum du nicht alle HAL Funktionen für die
> Serielle benutzt.

Was meinst du?

pegel schrieb:
> Die .ioc ist für einen L071RZ angelegt.

Ich hab das mit einem zweiten Chip getestet, aber die Pinbelegung ist 
gleich, daher der andere Chipname.

pegel schrieb:
> Übrigens gibt es für das aktuelle CubeMX 5.1.0 auch eine neue L0
> HAL-Lib.

Ich nutze aktuell die v5.0.0

pegel schrieb:
> Falls darin ein Fehler sein sollte der USART betrifft,
> wäre vielleicht ein Update einen Versuch wert.

Habe ich probiert. Nutze v5.1.0, keine Änderung zu sehen.

Hier mal der Code zum senden/empfangen:
uint8_t data = 'a';
HAL_StatusTypeDef ret;
while (1)
{
  HAL_Delay(100);
  ret =  HAL_UART_Receive(&huart1, &data, 1, 1000);
  if(ret == HAL_OK){
    __ASM volatile ("nop");
    HAL_UART_Transmit(&huart1, &data, 1, 1000);
  }
}

pegel schrieb:
> ist eine blockierende Funktion. Die alle 100ms aufzurufen und ihr 1s
> Timeout

Inwiefern sollte dies ein Problem sein? Innerhalb der Funktion wird eine 
Sekunde gewartet, danach wird ein Delay von 100ms erzeugt (Welchen ich 
komplett auslassen könnte) und dann wird erneut die Funktion aufgerufen.

Stefanus F. schrieb:
> Während der 100ms verpasst du empfangene Zeichen (falls es mehr als eins
> ist).

Ach darauf wolltest du hinaus. Ich sende durchgehend vom PC aus jeweils 
1 Zeichen ('a'). In der einen Sekunde Timeout-Zeit sollte mindestens 
eines dieser As empfangen werden. Ich kann den Delay auch entfernen, 
kein Problem, kommt jedoch dasselbe bei rum.

pegel schrieb:
> Dann mach es mal anders herum. Vergiss das Empfangen auf dem µC und
> sende jede Sekunde ein Zeichen zum PC Terminal Programm.

Es wird nichts übertragen. Ich rufe die Transmit Funktion auf und die 
LED an der Tx Leitung blinkt nicht mal. Der PC empfängt dementsprechend 
auch nichts.

Stefanus F. schrieb:
> Dachte ich mir schon. Dein Problem war ja, dass du gar nichts empfängst.

Ganz genau, das war eigentlich nur ein Test, um zu gucken ob eine 
Verzögerung etwas ändern würde.

pegel schrieb:
> Hast du ein anderes Board?
> Am Besten ein Bluepill und USB-Seriell Wandler?

Leider nein, versuche gerade das ganze ohne HAL, also reine 
Bit-Schieberei, zu realisieren.

pegel schrieb:
> probier mal ob da etwas kommt

Doofe Frage meinerseits... was mache ich mit der Hex-Datei?

Stefanus F. schrieb:
> Auf dein Board flashen!

Danke, hab ich gemacht. Wusste gar nicht, dass es diese Möglichkeit 
gibt.

pegel schrieb:
> Ich habe leider keinen L071 hier, aber probier mal ob da etwas kommt.

Nein, keine Reaktion.


Nur mal nebenbei, ich kann die Pins steuern, sprich ich kann die LED 
einfach zum Leuchten bringen, daher funktioniert zumindest die normale 
Funktion der Pins, was einen kompletten defekt ausschließt.

Danke dir, wäre sicherlich hilfreich!!

Ich hab mal ein Diagramm der Register im Anhang.
Alle Bits die ich rot markiert habe sind auf 0 gesetzt, die grünen auf 
1.
Was mich stark wundert, ist dass CubeMX den Quellcode so generiert, dass 
das Bit UE im CR1 zum Enablen des UARTS auf 0 ist.
Habe ich dann nachträglich selbst eingeführt.

Ist irgendwas an den Registern auffällig? Die beiden mit schwarz 
durchgestrichenen zeigt mir der huart gar nicht an.

Ich habe weitere Tests durchgeführt*:

USART1:
Rx und Tx reagieren nicht.
Die LED die an Rx angeschlossen ist blinkt wenn ich vom PC aus Daten 
sende.
Die LED die an Tx angeschlossen ist blinkt NICHT wenn ich vom MCU aus 
Daten sende.


USART2:
Rx und Tx reagieren nicht.
Die LED die an Rx angeschlossen ist blinkt NICHT wenn ich vom PC aus 
Daten sende.
Die LED die an Tx angeschlossen ist blinkt NICHT wenn ich vom MCU aus 
Daten sende.
Nach den ersten ca. 220 Bytes die ich sende schlägt die Receive Funktion 
einmalig um auf HAL_OK und gibt an den Wert 254 empfangen zu haben, 
obwohl ich ein 'b' sende (ist glaube ich 98). Anschließend erhalte ich 
nur noch HAL_TIMEOUT.

USART4:
Rx und Tx reagieren nicht.
Die LED die an Rx angeschlossen ist blinkt NICHT wenn ich vom PC aus 
Daten sende.
Die LED die an Tx angeschlossen ist blinkt NICHT wenn ich vom MCU aus 
Daten sende.

USART5:
Rx und Tx reagieren nicht.
Die LED die an Rx angeschlossen ist blinkt NICHT wenn ich vom PC aus 
Daten sende.
Die LED die an Tx angeschlossen ist blinkt NICHT wenn ich vom MCU aus 
Daten sende.



Da die LED bei einem USART blinkt und bei den anderen nicht, wird 
offensichtlich eine andere Pin-Konfiguration durchgeführt.








*Jedes mal wurde CubeMX genutzt zur Initialisierung

Daniel D. schrieb:
> Ich hab mal ein Diagramm der Register im Anhang.

> Ist irgendwas an den Registern auffällig?

Woher stammt denn das Bild? Das hat keinerlei Ähnlichkeit mit meinem 
Reference Manual (RM0377 für STM32L0x1). Das wäre evt. eine Erklärung 
dafür:

> Was mich stark wundert, ist dass CubeMX den Quellcode so generiert, dass
> das Bit UE im CR1 zum Enablen des UARTS auf 0 ist.

Wenn aber das Bild zu deinem Prozessor passt, warum ist SBK gesetzt? Und 
der Teiler im BRR passt zu einem CPU-Takt im kHz-Bereich?

Eigentlich wollte ich hier alle Beiträge noch beantworten, aber dann kam 
ich zu dem Punkt:

Stefanus F. schrieb:
> Am RxD Pin des µC  muss die LED völlig unabhängig von deiner Firmware
> flackern, denn das Signal kommt ja vom PC. Welche Spannung misst du dort
> in verbundenem Zustand ohne Datenübertragung und ohne LED?

Als ich mit dem Multimeter dran ging zum Prüfen wurden aufeinmal Daten 
versendet. Habe dann alles mögliche ausprobiert an der HW und habe jetzt 
am Ende herausgefunden, dass die LEDs, welche mir anzeigen sollten, ob 
die Leitungen genutzt werden, das Problem sind. Ich habe diese entfernt 
und seitdem funktionieren alle USARTs mit Senden und Empfangen außer 
USART1, der empfängt nichts sinnvolles oder gar nichts, kann aber 
wunderbar senden. Ich verstehe zwar nicht, warum es jetzt plötzlich 
geht, da ich zu Beginn auch keine LEDs verwendet habe und da nichts 
funktionierte, aber immerhin habe ich eine "Lösung".

Ich danke euch allen für die Unterstützung!