[fpga_student 0]

On 3/26/2023 at 10:57 PM, adnega said:

У Заказчика всяко может быть. Например, он изменяет какие-то уставки, которые в реальном времени щелкают каким-нить мощным контактором, от помехи которого МК сбоит - статистика в этом случае меняется кардинально.

хммм, это реально крутая бага, которую я ловил еще сам, когда кодил) Да я сегодня уже сам потребовал схему машины именно на этот предмет. Но меню настроек устроено так что ничего силовое ЕМНИП не работает во время настройки.

 

On 3/26/2023 at 10:57 PM, adnega said:

Самое простое - сделайте индикацию HardFault.

Это в плане, спасибо.

[jcxz 184]

6 минут назад, fpga_student сказал:

просто там действительно большая хрень

Я вам в самом начале дал дельный совет: Задействовать MPU для обнаружения несанкционированных обращений к регистрам программирования флешь. Вы проигнорили. Это вроде такая очевидная вещь, когда есть подозрения на какие-то непредусмотренные действия. И ваш великолепный почему-то до сих пор не сделал такой простой вещи. И похоже даже элементарную обработку HF не реализовал. Хотя уже наваял мегабайты там чего-то... А это - базовые вещи, с которых надо было начинать писать ПО. 

[fpga_student 0]

On 3/26/2023 at 11:02 PM, jcxz said:

Я вам в самом начале дал дельный совет: Задействовать MPU для обнаружения несанкционированных обращений к регистрам программирования флешь. Вы проигнорили. Это вроде такая очевидная вещь, когда есть подозрения на какие-то непредусмотренные действия. И ваш великолепный почему-то до сих пор не сделал такой простой вещи.

Эммм. Да я не понял. Имеете в виду завести прерывания какие-то менеджера памяти при обращении к флешь ?

Мне нужно DS почитать тогда.

 

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

 

У нас приложение bare metal, RTOS нет

[adnega 10]

В 26.03.2023 в 23:02, jcxz сказал:

Я вам в самом начале дал дельный совет: Задействовать MPU для обнаружения несанкционированных обращений к регистрам программирования флешь.

А как это принципиально поможет? Перед корректной записью флешь нужно временно регион MPU отключать, поработать, а затем включать?

Что помешает коду с ошибкой на этапе "поработать" наломать дров при выключенном MPU?

[jcxz 184]

Только что, fpga_student сказал:

Эммм. Да я не понял. Имеете в виду завести прерывания какие-то менеджера памяти при обращении к флешь ?

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

fault-ы от MPU нужно обрабатывать в числе прочих fault-ов. Обязательно. С индикацией и(или) занесением записи в анналы в логи.

Более того - любая приличная программа, выполняющаяся на CPU с MPU, просто обязана его использовать: определяя в какой области памяти что позволено делать - где код исполнять, где данные читать, а где - и писать даже. У меня например с помощью MPU (включенного и настроенного всегда с самых первых строк проекта) выявляется основная доля ошибок сделанных по невнимательности. Как только где-то я чуть лопухнулся, то в большом проценте случаев - идёт например попытка записи в несуществующие или const -адреса памяти. И тут же получаю fault с индикацией места и причины.

[fpga_student 0]

On 3/26/2023 at 11:12 PM, jcxz said:

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

Да спасибо. Теперь понятно

[jcxz 184]

7 минут назад, adnega сказал:

А как это принципиально поможет? Перед корректной записью флешь нужно временно регион MPU отключать, поработать, а затем включать?

Что помешает коду с ошибкой на этапе "поработать" наломать дров при выключенном MPU?

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

И обработка всех fault-ов во всём проекте конечно-же - обязательна.

[adnega 10]

В 26.03.2023 в 23:15, jcxz сказал:

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

Чтоб что-то сделать с флешь нужно как минимум разлочить работу с ней. По мне так это тоже самое, что MPU разлочить. Да, в нештатной ситуации MPU может дать дополнительную информацию о проблеме, а неразлоченный контроллер флешь (зависнет?) не даст эту самую флешь повредить. А так как ТС уверяет, что флешь стирается даже с локом сектора, то:

- выполняется полный код снятия защиты с сектора, стирание сектора, и уж точно разблокирование контроллера флешь по всем правилам (т.е. и MPU тоже будет временно отключен);

- либо никакого стирания флешь нет (опять же MPU тут не поможет).

[fpga_student 0]

On 3/26/2023 at 11:12 PM, jcxz said:

Более того - любая приличная программа, выполняющаяся на CPU с MPU, просто обязана его использовать

Спасибо написал программисту. И сам получил образование) Респект

 

On 3/26/2023 at 11:25 PM, adnega said:

Чтоб что-то сделать с флешь нужно как минимум разлочить работу с ней. По мне так это тоже самое, что MPU разлочить. Да, в нештатной ситуации MPU может дать дополнительную информацию о проблеме, а неразлоченный контроллер флешь (зависнет?) не даст эту самую флешь повредить. А так как ТС уверяет, что флешь стирается даже с локом сектора, то:

Да, меня вот это тоже беспокоит. Но лучше перебдеть, чем недобдеть. Составим список версий и отработаем все. Это лучший способ, я знаю)

[Сергей Борщ 119]

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

[EdgeAligned 53]

Написали конечно аж 4 страницы, но покуда топикстартер не вызвал программиста, писавшего сиё творение, и не попросил его заново пошагово, с модульными тестами, перепроверить "каждую зяпятую", это всё гадание на кофейной гуще. Я еще на первой странице писал - вначале следует проверить, вообще что-то исполняет микроконтроллер или нет? Ориентироваться надо не на белый экран дисплея, а на лог.анализатор и прослеживание выходных сигналов. В частности, генерация кварца, импульсы на выводе NRST, состояние выходов, рабочие сигналы SDRAM. Косвенно это поможет определить хотя бы примерно, запустился микроконтроллер ли, примерно где находится. Конечно, это нужно делать с программистом, поскольку он знает, что он программировал и какие сигналы в какой момент времени должны быть.

Когда будет выявлено, что кварц HSE запустился, тактирование SDRAM на выходе SDCLK есть, будет понятно, что прошивка не стерта. Дело в том, что запуск HSE обычно пишется в первую очередь после старта. Затем, в основной программе, как правило идет запуск SDRAM. После этого может быть подготовлен и запущен LTDC для дисплея, нужно проверить наличие тактовых сигналов на DCLK, HSYNC, VSYNC. Судя по белому экрану, как раз этих сигналов и нету. Берем исходники программы и смотрим, где в тексте по порядку от начала есть этот запуск LDTC и что может произойти до него по ходу программы. 
Если сигналов SDCLK тоже нет, значит смотрим так же участок программы непосредственно до запуска SDRAM. 
В зависимости от того, как была написана работа бутлоадера (загрузчика), с HSE или без него, сигнал работы кварца HSE тоже может служить контролькой. Генерацию на кварце лучше проверить осциллографом на выходе OSC_OUT, включив на щупе осцилла делитель 1:10 для снижения емкости щупа.
Возможно, что выход из бутлоадера не выполняется корректно после обновления прошивки, было неверно написано. Возможно, новая версия прошивки имеет косяки. То есть, попробуйте провести процедуру обновления прошивки через ваш бутлоадер. Это конечно же нужно тестировать перед выпуском.

Вообще, есть такая штука, как юнит-тесты, модульные тесты. Ваш программист должен об этом знать.

  

9 hours ago, fpga_student said:

Он чрезвычайно хорош. Единственный из 15 студентов

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

Вы вот отвергаете версию "железной" проблемы, отвергаете и софтовые ошибки, и не знаете, при каких обстоятельствах происходит "великое массовое вымирание" ваших плат. Так какую же причину вы желаете услышать?
Неее, тут надо в первую очередь порыться в своих ошибках.

PS. Смотрю схему. Нагрузочные кондеры на кварцах - ажно 250 В заявлены. 🙂 ИнтЭрЭсно, любопытно. А почему и на основании чего именно 250 В?

Изменено 27 марта, 2023 пользователем haker_fox
Нарушение правила 2.1.в.

[haker_fox 60]

Модератор: @EdgeAligned, пожалуйста, прочитайте правила 2.1.в.

[AlanDrakes 1]

10 часов назад, jcxz сказал:

Чувствую, что программист и сам не в курсе - кто там что у него в ПО пишет во флешь.   При таких-то размерах можно предположить - явно где-то надёргал чужого кода, который непонятно что внутри себя вытворяет.

Для одного проекта наваял простенький самописный загрузчик, прикрутил к нему UART и x-modem, чтобы каждый раз не разбирать устройство и не обновлять прошивку программатором.

В какой-то момент, обновляя прошивку, случайно указал .elf файл вместо .bin и заметил это только когда залилось уже 190кБ из 96 😕 В общем, счётчик страниц на STM32F103C8T6 успешно крутанулся и записал в загрузчик мусор. Хотя вроди бы всё проверял перед записью. Оказалось, что нет.

Так что от ошибок программиста никто не застрахован. И самое печальное, когда от своих ошибок не застрахован.

[fpga_student 0]

On 3/27/2023 at 7:45 AM, EdgeAligned said:

Написали конечно аж 4 страницы, но покуда топикстартер не вызвал программиста, писавшего сиё творение, и не попросил его заново пошагово, с модульными тестами, перепроверить "каждую зяпятую", это всё гадание на кофейной гуще.

За эти 4 страницы я очень благодарен уважаемым профи. В проекте 850 тысяч строк. Чего точно не будет, так это пошаговой проверки запятых)

 

Но за пошаговую очередность тестирования спасибо) чтото забыл, а чтото уже и не знаю просто. Буду смотреть ваш гайд.

 

On 3/27/2023 at 7:45 AM, EdgeAligned said:

PS. Смотрю схему. Нагрузочные кондеры на кварцах - ажно 250 В заявлены. 🙂 ИнтЭрЭсно, любопытно. А почему и на основании чего именно 250 В?

проект был одним из нескольких. Я не заставлял аппаратчика вылизывать либы. Он кинул компонент 0603 что было. Отсюда же номиналы на русском(( В проде на кварце разумеется стоит C0G (NP0) конденсатор, с нормальным рейтингом по напряжению, скорее всего 50В

[EdgeAligned 53]

В показанной схеме номинал индуктивности L1 указан 470 Ом. Но индуктивность измеряется не в Омах, а в Генри (Гн, мкГн, мГн). Сопротивление катушки - это уже дополнительный параметр. Поэтому лично я бы все-таки принял за основу вероятность ошибки разработчиков, собрал бы их вместе и начал бы все перепроверить ещё раз.

Случай, как вы говорите, не единичный, поэтому либо придётся уж потрудиться, либо, как я раньше написал, пытаться искать не в том месте. 

Все 850 тыс строк проверять не надо, тем более, что они взяты по большей части библиотечные (в части ГУИ). Проверять нужно то, как состыкованы эти куски и то, что было написано автором программы. 

PS. Стоит прочитать документ  ES0206 на сайте st.com, это эррата, список багов микроконтроллера. Там как раз есть кое-что про флеш

Изменено 27 марта, 2023 пользователем EdgeAligned