Думаю, ничего не упустили. Более того, операция записи нуля в SR бесполезна для битов ошибок, т.к. они Read Only, а для TC и RXNE может оказаться фатальной: смотрим мануал в части описания регистра SR и читаем:

The TC bit can also be cleared by writing a '0' to it. This clearing sequence is recommended only for multibuffer communication.
The RXNE flag can also be cleared by writing a zero to it. This clearing sequence is recommended only for multibuffer communication.

Да, эта часть бесполезна. Видимо, наследие какого-то другого контроллера
Но вреда от неё тоже нет

Насчет битиков ответ простой: я не пользуюсь сторонними библиотеками.

Насчет UARTа я пока уверен, что накакие заплатки не нужны, т.к. железо работает отлично. Но если у Вас есть желание переубедить меня, то
я с радостью помогу. Ибо я лучше сейчас огребу, чем в будущем. В свое время я сталкивался с потерей байт, но не придавал этому особого значения.
Старался писать код не чувствительным к таким потерям (точнее допускающим редкие потери с гарантированным восстановлением за конкретное время/
число перепосылок). Сейчас, когда начал копаться детально (где-то месяц назад), понял, что так или иначе аппаратура не виновата в потерях - виноват
исключительно софт. Если Вы считаете вопрос решенным (для своего круга задач), то, думаю, и копать дальше не стоит (меня тоже сейчас все устраивает).

Жесть .

Нет, я никого переубеждать не хочу, тем более человека, который даже библиотеками производителя процессоров не пользуется. Просто поделился информацией на случай, если кто сталкивался, но не понял, что происходит.

Да, все нормально: просто я с STM практически с самого начала (тогда и библиотеки никакой не было), поэтому библиотеки у меня свои.
Библиотеками производителя я пользуюсь, но только в ознакомительных целях. И документацию читаю внимательно.
Если честно, то до сих пор не понятно, в чем собственно проблема UART на STM32 и почему только у Вас UART теряет байты.
За информацию спасибо: если что-то не работает в сложной системе, то нужно вставлять задержки и дополнительные чтения статусных регистров.

Да библиотеки производителя все (ну большинство точно )с дисклаймером - это только пример!!! они в курсе качества их программистов, так что тоже не сторонник брать не глядя, и по большей части не использую.

А у вас окружающее UART железо нормальное? У нас было такое дело на драйвере в RS232 конденсаторы на землю не запаялись и при ненасыщенном обмене все работало, а в каких то критических случаях иногда проскакивали ошибки, когда от вида данных или еще от чего что-то там разряжалось, недозаряжалось, и уровни перли тупо не правильные...

местные программисты добавили контроль целостности и успокоились, а я осциллографом потыкал и увидел весь этот кавардак, как уровни медленно дрейфуют, может они уплывают и байт теряется?


И еще из интересных тестов я бы первой командой в прерывании пришел байт поставил бы счетчик входа в прерывание, а по сохранению байта в буфер счетчик сохраненных байт, и поглядел не расходиться ли это по ходу дела? Есть у меня такая теория что когда приходит прерывание вы в него вваливаетесь, потом вас куда то дергают, и за это время старый байт затирается, и вы пришли в прерывание за символом, а внутри получили ошибку и не сохранили символ. что-то типа того....

Я о CMSIS говорил.


Модуль WiFi и процессор находятся рядом на плате и общаются на TTL/CMOS уровне, без всяких RS-232. Я уверен, с этой точки зрения там все стабильно.