Jump to content

    

Neo_Matrix

Участник
  • Content Count

    78
  • Joined

  • Last visited

Everything posted by Neo_Matrix


  1. Столкнулся со странным поведение периферии 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 вышеописанных метода решения это "костыли" чистой воды, прошу помочь проблему более правильно.
  2. Добавил проверку ошибок UART по принципу проверили флаг -> напечатали принтом ошибку -> сбросили флаг. Несколько раз при горячем отключении ошибки проскакивали, но UART от их обработки виснуть не перестал.
  3. ORE - проверяю, на остальные прерывания отключены. В дебагере четко видно, что ни один из флагов(FE и т.д.) в момент зависания приема - не выставлен, кроме того, как объяснить продолжение нормальной работы после записи в регистр DR(чтение этого регистра проблему не убирает!)
  4. Просмотрел еррату, есть похожая ошибка, но она проявляет себя только при аппаратном контроле потока, который у меня выключен. В итоге непонятно.
  5. Неполадки с очередью в USART

    Рекомендую прикрутить 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); }
  6. Неполадки с очередью в USART

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

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

    Достаточно долго работаю с FreeRTOS и могу вас заверить, что критических ошибок приводящих к мертвым зависаниям в ней нет(с версии 8 точно). То, что после обновления ОС, ошибка пропала, скорее всего говорит о том, что ошибка была "скрыта", а не решена. Скорее всего при следующих правках кода ошибка снова проявит себя. Посмотрите в сторону прерываний hard_fault, bus_fault и им подобным(они включены в не зависимости от хотелок), предположу: при зависании вылетает в них. ПС: В "обновляторе прошивок" использую только очереди, даже при приеме данных с модема в прерывании(оверхед эпичный), но даже в таком режиме(а данных пересылается достаточно много) никогда нечего не висло. Кроме того внутри одной задачи используется парсер пришедших данных и они раскладываются по разным очередям а после этой же задачей вычитываются(не хотелось добавлять левые буферы) и даже такое издевательство не вешает контроллер.
  11. Спасибо за ответы! Она выпускается в нескольких вариантах с фиксированным напряжением и с настраиваемым. Конкретно LD29300P2MTR с настраиваемым, у остальных другие индексы. Модем должен быть включен постоянно, это часть ТЗ. Все остальное уже запитано от другого стабилизатора на NCP... Посмотрел даташиты на BISS транзисторы - они идеально подходят для данной задачи. Схему немного переделаю, так как ноги МК недоступны, можно сказать модуль модема внешний и имеет только линии RX, TX, GND, VCC(3.4 - 4.2 или 4.4). Еще раз спасибо за пинок в правильном направлении - BISS.
  12. Спасибо за содержательный пост, завтра просмотрю документацию по микросхемам. Проблем с покупкой LD29300 несколько. Поскольку изделия нам делают под ключ, два изготовителя написали о проблемах с их поставками. К сожалению e-find - это российский поисковик, а наши поставщики(изготовители) работают с Европой или Китаем. Эти микросхемы есть с фиксированным напряжением и подстраиваемым, с первыми проблем нет, со вторыми есть(Можете сами убедится посмотрев эту позицию на МАУСЕРе).
  13. А вот выдержка из даташита другого LDO.
  14. LDO на основе ПТ часто уходят в возбуд особенно если нагрузка не стабильная. Эффект "нестабильности" можно наблюдать у LDO серии MIC29xxx при малом токе потребления эта серия выдает на выходе напряжение которое выше установленного с помощью пина ADJ. При небольшом увеличении тока все сразу приходит в норму.
  15. LDO очень не стабильны, потому хотелось проверенное решение, а не делать велосипед, а после ехать на нем по граблям.
  16. В общем, поскольку, обсуждение приходит к руслу: "у вас все неправильно" или "поменяйте АКБ" предлагаю для начала изучить: 1) Суть проблемы. 2) Применяемую микросхему заряда, ее скриншот прикреплен выше. 3) Модемный модуль отдельное устройство и в основную часть устройства вмешиватся никто не будет. Считаем что оно опломбировано. 4) Модемный модуль который применялся ранее имел более широкий диапазон напряжений, сейчас он снят с производства. На его замену был выбран СИМ800 и альтернатив по соотношению цена\качество сети\EAT у него попросту нет.
  17. Почитайте внимательно!!!! АКБ имеет напряжение 4.2 ВОЛЬТА! Прикрепил скрин на микросхему, там все видно, откуда берутся 4,4
  18. Посоветуйте варианты... LDO серии MIC и SEP ведут себя плохо при входном напряжении ниже 5 вольт или нагрузке в микроамперы. Так же актуальна стоимость, чип за 2-3 бакса на лезет в бюджет, при стоимости модема менее 5 баксов. Ранее применяемая LD29300 стала сложно доставаемой, но цена вполне приемлемая при покупке ленты.
  19. Не понял к чему это все было сказано? Будьте внимательны, вопрос абсолютно иной!
  20. Я не писал, что АКБ 4.4 вольта, вроде четко написал, что на выходе стабилизатора. Акб на 4.2 вольта, кроме того тот же литий-полимер можно заряжать до 4,4 с контролем температуры и т.д. В самсунге S3 штатное напряжение 4,3 вольта, а во всяких сяоми так и вообще 4,4. Сложно понять какое отношение типа акб имеет к прямому ответу на вопрос, но для тех, кто хочет понять суть прикрепил скриншот.
  21. В выключенном состоянии микроамперы, во время поиска сети до 2х ампер(по рекомендациям даташита), в остальное время 10-200мА
  22. Каким образом можно сделать металлизированные отверстия покрытыми маской? По умолчанию есть слои tStop, bStop - по которым можно сформировать слои маски, но все отверстия на этих слоях не покрываются маской, а для меня важно, что бы они были покрыты маской. Единственный способ, что я нашел - скопировать эти слои на новый слой и в ручную удалить все, что касается переходных отверстий. Есть ли более изящный способ?
  23. Решил сделать проще, буду использовать СТМ32, как аппаратный TLS кодер\декодер трафика, ресурсов хватает за глаза...