Overrun-Fehler mit zwei USART-interrupts

Mit zwei USARTs läuft auf 115200 baud auf einem STM32F2, eine Kommunikation mit einem radio-Modul und eine für die serielle vom PC. Die Taktfrequenz 120MHz.

Beim empfangen von Daten von beiden USARTs gleichzeitig overrun-Fehler kann auftreten, auf einem USART oder die andere. Tun einige schnelle Rückseite der Umschlag Berechnungen es sollte genügend Zeit zur Bearbeitung sowohl, als die interrupts sind einfach nur kopiere das byte in Ringpuffer.

Sowohl In der Theorie und aus der Messung der interrupt-code, um push-byte-Puffer-soll/muss in der Reihenfolge ausgeführt, von 2-4µS, bei 115200 baud haben wir rund 70us zu verarbeiten jeden char.

Warum sehen wir gelegentliche Erze auf die eine oder andere USART?

Update - weitere Informationen:

  1. Keine anderen ISRs in unserem code sind brennen in dieser Zeit.
  2. Wir laufen Keil RTX mit systick-interrupt konfiguriert, um das Feuer alle 10mS.
  3. Wir sind nicht der Deaktivierung der interrupts zu diesem Zeitpunkt.
  4. Nach diesem Buch (Dem Designer ' s Guide to the Cortex-M Prozessor-Familie) die Interrupt-Latenzzeit ist um 12cycles (nicht wirklich aggressiv)

Angesichts all der oben 70us ist mindestens ein Faktor von 10 über der Zeit, wir nehmen Sie zum löschen der interrupts - also ich bin mir nicht sicher, seine so einfach zu erklären. Sollte ich zu dem Schluss, dass es muss einen anderen Faktor bin ich über die Suche?

MDK-ARM version 4.70

Den systick-interrupt verwendet wird, durch den RTOS-also nicht mal die anderen ISRs 2-3µS laufen pro byte.

  • Sie haben nicht genug Informationen für jemanden zu sagen, warum Sie speziell sind immer überrollt. Offensichtliche Kandidaten: Deaktivieren von interrupts woanders? Höhere Priorität interrupt-handler zu langsam? Fehler im code? Nicht genug Informationen, um herauszufinden, welche.
  • ISR Latenz ist ziemlich tödlich auf, dass die chip -, die UARTs nicht über einen fifo-Puffer. Ihre theoretische Berechnung ist bereits um den Faktor zwei. Hinzufügen von höherer Priorität unterbricht dessen ISR zu viel Zeit oder unterbricht immer deaktiviert im code, den Sie nicht kennen, und einen überlauf bekommt, um einfach zu erklären.
  • Vielen Dank für die Kommentare, die ich Hinzugefügt habe, sind einige weitere Informationen zu der Frage, ich bin mir nicht sicher, welche anderen Informationen, die ich bieten kann.
  • Welche version von RTX (oder ARM-MDK)? Frühe Versionen für Cortex-M3 hatte bugs und nicht voll und ganz unterstützen interrupt-Priorität gruppieren. Vielleicht ist die Frage nicht zu beantworten ohne den code.
  • Wie lange dauert die systick-interrupt zur Ausführung? Kann der systick-ISR unterbrochen werden die USART-interrupts? Was ist die interrupt-Latenz für alle drei?
  • Ich gehöre nicht zu geben bis auf ein ungeklärtes problem dar, da die Symptome zeigen, bis später anderswo. Noch, für meine letzten Projekte habe ich immer schon mit DMA zu erstellen, die einem Ringpuffer speichert die empfangenen Daten vom USART. Eigentliche hardware (DMA-controller) einfach nicht verpassen Termine (es sei denn, es ist zu überladen, aber es sei denn, du verwendest es für etwas anderes, 2 USARTs zu diesem Kurs sollte ein Stück Kuchen).
  • Ist es möglich, dass der Prozessor schlief zu der Zeit? Laut Datenblatt, das aufwachen aus dem stop-Modus kann normalerweise nehmen 110 uns in gewissen Umständen, und aufwachen aus dem standby-Modus dauert mindestens 260 uns. Auch kann man ein kleines Projekt, entfernen Sie so viel code wie möglich, also reproduziert diesen bug? Vor allem, wenn Sie aus jeder anderen unterbrechen (einschließlich der RTOS) und nicht immer legen Sie den Prozessor in den sleep-Modus. Das könnte ein Anzeichen für irgendeine Art von hardware-Fehler (die Art, die sollte gehen in ein errata-Blatt).
  • Sie können nicht deaktivieren interrupts vollständig, aber tun Sie Ihre PRIMASK hoch genug, um deaktivieren Sie den UART-interrupts (möglicherweise versehentlich)? Ich weiß, FreeRTOS wird dies auf dem CM3, damit Sie noch "schnelle" interrupts, die nicht mit dem OS, aber Sie brauchen, um über eine bestimmte Priorität zu.

InformationsquelleAutor Jonathan Moreton | 2014-04-15
  1. 2

    Ich lief in ein ähnliches problem wie deins vor ein paar Monaten auf einem Cortex M4 (SAM4S). Ich habe eine Funktion, die aufgerufen wird, auf 100 Hz basiert auf einem Timer-Interrupt.

    In der Zwischenzeit hatte ich eine UART konfiguriert zu unterbrechen, die für char-Rezeption. Die erwarteten Daten über UART 64 byte lange Pakete und unterbrechen auf jeden char verursacht Latenz, so dass meine 100-Hz-update-Funktion ausgeführt wurde, bei etwa 20 Hz. 100 Hz ist relativ langsam auf das insbesondere 120 MHz-Prozessor, aber die Unterbrechung auf jedem char war, was zu massiven Verzögerungen.

    Habe ich beschlossen zu konfigurieren, die UART zu verwenden, PDC (Peripheral DMA-controller) und meine Probleme verschwanden sofort.

    DMA ermöglicht den UART, um Daten zu speichern im Speicher OHNE Unterbrechung der Prozessor, bis der Puffer voll ist, spart viel Aufwand.

    In meinem Fall, sagte ich PDC zum speichern von UART-Daten in einem Puffer (byte-array) angegeben und die Länge. Wenn die UART per PDC füllte den Puffer der PDC gab einen interrupt.

    PDC ISR:

    1. Geben PDC neuen, leeren Puffer
    2. Neu starten UART-PDC (also Daten sammeln können, während wir andere Sachen in der isr)
    3. memcpy Puffer voll ist, in RINGBUFFER
    4. Ausfahrt ISR

    Als swineone oben empfohlen, implementieren DMA und du wirst das Leben lieben.

    InformationsquelleAutor hbAlex
  2. -1

    Hatte ein ähnliches problem. Kurze Lösung - ändern oversampling 8 bits, die macht USART clock präziser. Und wählen Sie Ihre MCU-clock mit bedacht!

    huart1.Init.OverSampling = UART_OVERSAMPLING_8;

    Darüber hinaus fügen Sie USART-Fehler-handler und-Mechanismus, um zu überprüfen, dass Ihre Daten gültig wie CRC16. Hier ist ein Beispiel für die STM32F0xx Serie, ich nehme an, es sollte ziemlich ähnlich über die Serie.

    void UART_flush(void) {
  //Flush UART RX buffer if RXNE is set
  if READ_BIT(huart1.Instance->ISR, USART_ISR_RXNE) {
    SET_BIT(huart1.Instance->RQR, UART_RXDATA_FLUSH_REQUEST);
  }

  //Not available on F030xx devices!
  //SET_BIT(huart1.Instance->RQR, UART_TXDATA_FLUSH_REQUEST);

  //Clear All Errors (if needed)
  if (READ_BIT(huart1.Instance->ISR, USART_ISR_ORE | USART_ISR_FE | USART_ISR_NE)) {
    SET_BIT(huart1.Instance->ICR, USART_ICR_ORECF | USART_ICR_FECF | USART_ICR_NCF);
  }
}

//USART Error Handler
void HAL_UART_ErrorCallback(UART_HandleTypeDef *huart) {
  if(huart->Instance==USART1) {
    //See if we have any errors
    if (READ_BIT(huart1.Instance->ISR, USART_ISR_ORE | USART_ISR_FE | USART_ISR_NE | USART_ISR_RXNE)) {
        //Flush errors
        UART_flush();

        //Raise Error Handler
        _Error_Handler(__FILE__, __LINE__);
    }
  }
}

    DMA könnte helfen, wie gut. Mein problem wurde im Zusammenhang mit der USART clock Toleranzen, die könnte sogar dazu führen, overrun-Fehler mit dem DMA umgesetzt. Da ist es USART hardware-problem. Anyway, ich hoffe das hilft jemandem da draußen! Prost!

    InformationsquelleAutor Barmaley
Schreibe einen Kommentar