Neo_Matrix

Столкнулся со странным поведение периферии UART4(на других не замечено), а точнее подвисанием. Итак имеется 2 устройства одно из них мое второе третьей стороны, оба устройства подключены по RS232. С моей стороны стоит процессор STM32F407 за ним MAX3232(питание от 3.3вольта) с сапрессорами с другой стороны находится такая же MAX3232 с сапрессорами далее уходит на проц(не смотрел какой). Так вот недалекий обслуживающий персонал частенько вынимает коннектор RS232 "на горячую", поскольку мое устройство питается от блока питания стороннего устройства земли(GND) у них в этот момент не разрываются, но конструкция разъема такова, что при попадании на металлический корпус коннектора RX, TX могут на него замкнуть(от этого защищают резисторы и сапрессоры). Теперь суть проблемы: В момент отключения кабеля посылка данных приходящих ко мне может быть принята не полностью, на что мой софт отвечает NACK(0x15), по непонятной мне причине в этот момент может выставится флаг LBD, который используется если настроить порт как LIN, но я не использую этот самый LIN и он не активен и прерываний от него нет, именно в такие моменты периферия подвисает. Если потом вернуть разъем на место, то прерывания RXNE, TXE более не срабатывают, а софт моей задачи вылетает по таймауту. В начале попробовал сбрасывать сам флаг LBD - флаг нормально сбрасывается но передача не возобновляется. Нашел 2 способа решить проблему костылем: 1) Сбросить ЮАРТ периферию и заново перенастроить. 2) При появлении флага LBD в регистре DR содержится(в случае зависания всегда) значение 0x0015(Мой ответ NACK). Если произвести запись в регистр любых данных все начинает снова работать, даже не нужно сбрасывать LBD. LBD - продолжаю сбрасывать для того что бы хоть как то отследить повторение зависания. Еще раз повторюсь функционал LIN Не используется мной, а отслеживание флага LBD сделано для работы костыля. Так же повторюсь, что прерывания после такой ситуации именно перестают срабатывать, а не ПО подвисает в прерывании. Использую следующую инициализацию порта: LL_USART_DisableRTSHWFlowCtrl(UART4); LL_USART_DisableCTSHWFlowCtrl(UART4); LL_USART_DisableLIN(UART4); LL_USART_DisableSCLKOutput(UART4); LL_USART_DisableSmartcard(UART4); LL_USART_DisableIrda(UART4); LL_USART_DisableHalfDuplex(UART4); LL_USART_SetTransferDirection(UART4, LL_USART_DIRECTION_TX_RX); LL_USART_SetParity(UART4, LL_USART_PARITY_NONE); LL_USART_SetDataWidth(UART4, LL_USART_DATAWIDTH_8B); LL_USART_SetStopBitsLength(UART4, LL_USART_STOPBITS_1); LL_USART_SetOverSampling(UART4, LL_USART_OVERSAMPLING_16); LL_USART_SetBaudRate(UART4, RCC_GetPCLK1ClockFreq(RCC_GetHCLKClockFreq(RCC_GetSystemClockFreq())), LL_USART_OVERSAMPLING_16, baudrate); LL_USART_Enable(UART4); LL_USART_EnableIT_RXNE(UART4); Может кто то сталкивался с такой ситуацией? Так как 2 вышеописанных метода решения это "костыли" чистой воды, прошу помочь проблему более правильно.

Добавил проверку ошибок UART по принципу проверили флаг -> напечатали принтом ошибку -> сбросили флаг. Несколько раз при горячем отключении ошибки проскакивали, но UART от их обработки виснуть не перестал.

ORE - проверяю, на остальные прерывания отключены. В дебагере четко видно, что ни один из флагов(FE и т.д.) в момент зависания приема - не выставлен, кроме того, как объяснить продолжение нормальной работы после записи в регистр DR(чтение этого регистра проблему не убирает!)

Просмотрел еррату, есть похожая ошибка, но она проявляет себя только при аппаратном контроле потока, который у меня выключен. В итоге непонятно.

Рекомендую прикрутить Percepio Tracealyzer и посмотреть все что происходит с ОСью, в частности будет видно кто что вызывает. Где-то на форуме проскакивала "не жадная" версия. И попробуйте функцию отправки изменить на: void USART_putc(int c) { char xC = (char) c; GPIO_set_HIGH(GPIO_LED); xQueueSendToBack(hal_USART.xTX, &xC, pdMS_TO_TICKS(1)); USART3->CR1 |= USART_CR1_TXEIE; GPIO_set_LOW(GPIO_LED); }

На M4F с АРМ компилятором 6-версии нечего не ломается с включенным LTO. По правде абсолютно не вижу смысла в LTO, размер кода уменьшается на сущие копейки, а в скорости и вовсе нет прибавки.

С помощью чего можно сбросить 0.2 вольта для запитки модема SIM800. Предел напряжений питания модема от 3,4 до 4,4 - на выходе стабилизатора(он же ЗУ для АКБ) 4,4вольта, т.е. на границе напряжения питания модема, в некоторых случаях модемы выдают информацию о превышении питания. При этом ставить диод как то не разумно, так как устройство еще и работает от аккумулятора. Сейчас использую LD29300, но она дорогая и последнее время сложно доставаемая, ее достоинство в том, что она стабилизирует напряжение до 4,2 вольта, а при разряде АКБ ниже этого предела ведет себя как ключ с низким падением напряжения по сути выступая в роли ограничителя напряжения. Какие будут предложения, можно даже на рассыпухе?

Апноуты весьма интересны особенно про керамические конденсаторы. Благодарю!

Не вижу смысла удалять неиспользуемые функции, все что не используется нормально выпиливается встроенными макросами ОСи. Относительно атрибута used для LTO есть более правильное решение с точки зрения "красивости кода" оно описано в тикете под номером 90. А вот изменяя файлы порта есть большой шанс что то сломать. Если используется Кеил, у него многоие обработчики прерывания описаны в стартап файле, и если вы попадете в один из них отладчик не может показать где он сейчас находится(по крайней мере джетлинк). Допустим такой: BusFault_Handler\ PROC EXPORT BusFault_Handler [WEAK] B . ENDP ПС: Перед написанием комментария не обновил страницу.... Потому несколько устаревший

Достаточно долго работаю с FreeRTOS и могу вас заверить, что критических ошибок приводящих к мертвым зависаниям в ней нет(с версии 8 точно). То, что после обновления ОС, ошибка пропала, скорее всего говорит о том, что ошибка была "скрыта", а не решена. Скорее всего при следующих правках кода ошибка снова проявит себя. Посмотрите в сторону прерываний hard_fault, bus_fault и им подобным(они включены в не зависимости от хотелок), предположу: при зависании вылетает в них. ПС: В "обновляторе прошивок" использую только очереди, даже при приеме данных с модема в прерывании(оверхед эпичный), но даже в таком режиме(а данных пересылается достаточно много) никогда нечего не висло. Кроме того внутри одной задачи используется парсер пришедших данных и они раскладываются по разным очередям а после этой же задачей вычитываются(не хотелось добавлять левые буферы) и даже такое издевательство не вешает контроллер.

Спасибо за ответы! Она выпускается в нескольких вариантах с фиксированным напряжением и с настраиваемым. Конкретно LD29300P2MTR с настраиваемым, у остальных другие индексы. Модем должен быть включен постоянно, это часть ТЗ. Все остальное уже запитано от другого стабилизатора на NCP... Посмотрел даташиты на BISS транзисторы - они идеально подходят для данной задачи. Схему немного переделаю, так как ноги МК недоступны, можно сказать модуль модема внешний и имеет только линии RX, TX, GND, VCC(3.4 - 4.2 или 4.4). Еще раз спасибо за пинок в правильном направлении - BISS.

Спасибо за содержательный пост, завтра просмотрю документацию по микросхемам. Проблем с покупкой LD29300 несколько. Поскольку изделия нам делают под ключ, два изготовителя написали о проблемах с их поставками. К сожалению e-find - это российский поисковик, а наши поставщики(изготовители) работают с Европой или Китаем. Эти микросхемы есть с фиксированным напряжением и подстраиваемым, с первыми проблем нет, со вторыми есть(Можете сами убедится посмотрев эту позицию на МАУСЕРе).

А вот выдержка из даташита другого LDO.

LDO на основе ПТ часто уходят в возбуд особенно если нагрузка не стабильная. Эффект "нестабильности" можно наблюдать у LDO серии MIC29xxx при малом токе потребления эта серия выдает на выходе напряжение которое выше установленного с помощью пина ADJ. При небольшом увеличении тока все сразу приходит в норму.

LDO очень не стабильны, потому хотелось проверенное решение, а не делать велосипед, а после ехать на нем по граблям.

Спасибо за бесценный совет!

В общем, поскольку, обсуждение приходит к руслу: "у вас все неправильно" или "поменяйте АКБ" предлагаю для начала изучить: 1) Суть проблемы. 2) Применяемую микросхему заряда, ее скриншот прикреплен выше. 3) Модемный модуль отдельное устройство и в основную часть устройства вмешиватся никто не будет. Считаем что оно опломбировано. 4) Модемный модуль который применялся ранее имел более широкий диапазон напряжений, сейчас он снят с производства. На его замену был выбран СИМ800 и альтернатив по соотношению цена\качество сети\EAT у него попросту нет.

Почитайте внимательно!!!! АКБ имеет напряжение 4.2 ВОЛЬТА! Прикрепил скрин на микросхему, там все видно, откуда берутся 4,4

Посоветуйте варианты... LDO серии MIC и SEP ведут себя плохо при входном напряжении ниже 5 вольт или нагрузке в микроамперы. Так же актуальна стоимость, чип за 2-3 бакса на лезет в бюджет, при стоимости модема менее 5 баксов. Ранее применяемая LD29300 стала сложно доставаемой, но цена вполне приемлемая при покупке ленты.

Не понял к чему это все было сказано? Будьте внимательны, вопрос абсолютно иной!

Я не писал, что АКБ 4.4 вольта, вроде четко написал, что на выходе стабилизатора. Акб на 4.2 вольта, кроме того тот же литий-полимер можно заряжать до 4,4 с контролем температуры и т.д. В самсунге S3 штатное напряжение 4,3 вольта, а во всяких сяоми так и вообще 4,4. Сложно понять какое отношение типа акб имеет к прямому ответу на вопрос, но для тех, кто хочет понять суть прикрепил скриншот.

В выключенном состоянии микроамперы, во время поиска сети до 2х ампер(по рекомендациям даташита), в остальное время 10-200мА

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

Спасибо! Проглядел настройку в DRC.

Решил сделать проще, буду использовать СТМ32, как аппаратный TLS кодер\декодер трафика, ресурсов хватает за глаза...