[fpga_student 0]

Добрый день. 

 

Уже писал один раз не нашел старую тему. 
Есть проект с дисплеем на stm32f429 с SDRAM. У платы есть функция обновления прошивки (те загрузчик), и более того, одна из страниц памяти процессора используется для хранения настроек машины. Плата реализует оконный интерфейс HMI на touchgfx. Довольно большой проект (порядка 20 окон) и куча сервисов.

 

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

 

Есть ощущение что вероятность сбоя существенно увеличивает импульсная помеха по питанию либо по воздуху.

 

В прошлый раз здесь обвинили моего программиста в ошибке, сказали у СТМ багов нет. Однако то что ситуация воспроизводится именно со включенной защитой, наводит на мысли об обратном.

 

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

 

Другого пути отладить проблему не вижу, а FRAM в серии и по старым временам было недешево, тем более сейчас. Кто интересно как решает подобные проблемы ? Как вообще новую железку в прод выводить и вот от таких багов себя обезопасить ?

[jcxz 236]

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

Однако то что ситуация воспроизводится именно со включенной защитой, наводит на мысли об обратном.

 

Сижу печалюсь, заказчику платы со снятой защитой отдать не вариант.

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

Это в плане паранойи  

А в практическом плане, ваш программист мог бы элементарно поставить защиту (через MPU) на регион регистров работы с флешем. Чтобы отловить несанкционированные обращения к ним (из-за глюков в ПО). Это самое простое и эффективное, что можно сделать. Буквально за несколько минут. По выявлению программных багов. А затея с FRAM, имхо - бесперспективна.

[fpga_student 0]

On 3/26/2023 at 7:25 PM, jcxz said:

А может это происки коварного заказчика, который таким макаром хочет у вас выцыганить прошивку? Чтобы потом клоны клепать.  

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

 

On 3/26/2023 at 7:25 PM, jcxz said:

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

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

 

On 3/26/2023 at 7:25 PM, jcxz said:

А в практическом плане, ваш программист мог бы элементарно поставить защиту (через MPU) на регион регистров работы с флешем. Чтобы отловить несанкционированные обращения к ним (из-за глюков в ПО). Это самое простое и эффективное, что можно сделать. Буквально за несколько минут. По выявлению программных багов.

В этом все дело. На секторе загрузчика стоит блокировка записи. А дохнет, с вероятностью 90% - именно он. Я write lock fuse на 0 блоке памяти вижу потом на дохлых платах, в панели фузов, когда снимаю блокировку памяти с проца.

 

On 3/26/2023 at 7:25 PM, jcxz said:

А затея с FRAM, имхо - бесперспективна.

Почему ? Это же дает статистику, в какой части программы все умирает ?

[EdgeAligned 86]

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

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

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

[fpga_student 0]

On 3/26/2023 at 8:09 PM, EdgeAligned said:

А он точно стирается? Может, просто не запускается или запускается не с того места?

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

 

On 3/26/2023 at 8:09 PM, EdgeAligned said:

И после выполнения каких действий такое происходит?

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

 

On 3/26/2023 at 8:09 PM, EdgeAligned said:

В поиске неисправности очень важно собрать информацию о том, при каких обстоятельствах и при каких действиях случается неисправность.

Я конечно очень давно программировал сам) но отлично это понимаю)

 

On 3/26/2023 at 8:09 PM, EdgeAligned said:

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

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

 

On 3/26/2023 at 8:09 PM, EdgeAligned said:

Так же такие же "показания" нужно взять с проектировщиков схемы и печатной платы.

Каким образом может повлиять железо на проблему ? С землей/питанием в проекте все в порядке, у меня был опытный проектировщик pcb. Насколько я понимаю помеха/наводка на шине SDRAM не должна привести к записи процом во флеш в запрещенный к записи адрес.

[EdgeAligned 86]

Ну, как бы без расспросов и выяснения обстоятельств наступления "смерти" можно долго и непродуктивно гадать.
И конечно же надо выяснить, где именно стерлась программа, стерлась ли действительно, или же просто банально зависон произошел и МК сидит в hard fault из-за каких-либо ошибок программиста.
Железо тоже может повлиять, и капитально так. Классический пример - неподключенная ножка BOOT0. Или же ошибки в подводе питания ко всем выводам. Так же банально из-за ошибок схемы и незащищенных входов/выходов микроконтроллер может просто сгореть.

Подробностей вы не описываете, поэтому я пишу просто возможные варианты.

 

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

В память проца пишет несколько функций, как у загрузчика (обновление основной прошивки), так и у основной программы (настройки проекта).

Более безопасно для этого использовать область Backup SRAM микроконтроллера, правда её питать нужно от батарейки или ионистора.

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

[fpga_student 0]

On 3/26/2023 at 8:20 PM, EdgeAligned said:

Ну, как бы без расспросов и выяснения обстоятельств наступления "смерти" можно долго и непродуктивно гадать.
И конечно же надо выяснить, где именно стерлась программа, стерлась ли действительно, или же просто банально зависон произошел и МК сидит в hard fault из-за каких-либо ошибок программиста.

Плата в серии. Штатно все стартует и работает, пока не чудо.

 

On 3/26/2023 at 8:20 PM, EdgeAligned said:

Железо тоже может повлиять, и капитально так. Классический пример - неподключенная ножка BOOT0. Или же ошибки в подводе питания ко всем выводам. Так же банально из-за ошибок схемы и незащищенных входов/выходов микроконтроллер может просто сгореть.

Идет серия. Идиотских ошибок в изделии нет. 

[EdgeAligned 86]

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

[fpga_student 0]

пользователи клиенты клиентов, доступа к ним нет.

 

еще раз спрашиваю почему идея с логгером плоха ?

[EdgeAligned 86]

Да как в анекдоте: "Ты чего по полу лазишь? -- Да я вон там ключи потерял. -- Так и ищи там, а не здесь! -- А здесь светлее!".

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

 

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

[fpga_student 0]

On 3/26/2023 at 8:30 PM, EdgeAligned said:

Да как в анекдоте: "Ты чего по полу лазишь? -- Да я вон там ключи потерял. -- Так и ищи там, а не здесь! -- А здесь светлее!".

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

Как я могу знать если на прошивке стоит лок на чтение ? Железо в проде, идет серия, я уже 2 раза написал. Отладчик невозможно подключить. Пользователи мне недоступны, только дохлые тела железок

[EdgeAligned 86]

Ну раз не стартует, а после перепрошивки снова работает как положено, значит, вызывайте погромиста программиста вашего, пусть приносит материалы и пошагово проверяйте, что именно он там понаписал. Баги СТМ-а описаны в его еррате, это должне значть каждый. То, что не описано, в 99% случаев - баги погромиста, как показывает практика.

 

Модератор: про правила 2.1.а и 2.1.в не забываем.

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

[fpga_student 0]

On 3/26/2023 at 7:25 PM, jcxz said:

А затея с FRAM, имхо - бесперспективна.

Обьясните, плз, почему Вы так считаете

[EdgeAligned 86]

Да потому что это костыль какой-то. Лучше уж область Bakup SRAM в самом микроконтроллере, она не стирается при перезапуске и не требует изменения схемы, кроме впаивания дисковой батарейки. Опять же, если не накосячит погромист. Хотя, он может так же накосячить и с FRAM.

 

[fpga_student 0]

On 3/26/2023 at 8:42 PM, EdgeAligned said:

Да потому что это костыль какой-то. Лучше уж область Bakup SRAM в самом микроконтроллере, она не стирается при перезапуске и не требует изменения схемы, кроме впаивания дисковой батарейки. Опять же, если не накосячит погромист. Хотя, он может так же накосячить и с FRAM.

Хм. А батарейка-то в системе есть. Мысль неплоха. Да спасибо. Fram хочется потому что он энергонезависимый. Baсkup SRAM зато быстрый.

 

Интересно при сбросе защиты и стирании проца Baсkup SRAM стирается или нет ?