Arlleex 131 12 июля, 2018 Опубликовано 12 июля, 2018 · Жалоба А эскалация - это когда к примеру у Вас запрещён BusFault, но происходит причина его вызывающая и, так как он запрещён, то происходит эскалация до HF. У меня обработка всех fault-ов построена на эскалации до HF - так проще, чем писать кучу обработчиков с одинаковыми действиями. В ISR HF по регистрам всегда можно определить первоначальный источник, до эскалации. Ну да. На самом деле-то вот что интересно: вообще возможно ли сделать так, чтобы "вычислить" начальное место, откуда пошло затирание памяти :rolleyes: Вангую, что нет :biggrin: Разве что всегда при входе проверять аргументы на заданные диапазоны (указатели тем более) и в случае чего делать assert() с тем же вызовом SVC и записью в журнал. Да и не совсем очевидно, что делать, если в функцию пришли не ожидаемые параметры (к пример, слишком большой объем запрашиваемых данных на копирование) - совсем не отрабатывать (прямой return из функции), копировать по максимальному ожидаемому размеру, и т.д. Обычно такие ситуации я передаю наверх по стеку вызовов и там уже на уровне логики принимаю решение - делать ли перезапрос, например :laughing: А вот насчет порчи памяти третьим лицом (функцией в нашем случае) - вещь тоже довольно интересная, случалось сталкиваться с таким, причем даже с отладчиком порой можно просидеть день, ничего не надебаживши. Правда в таких случаях меня все-таки спасают assert-ы по входу функций. Сразу видно кому снесло голову. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 12 июля, 2018 Опубликовано 12 июля, 2018 · Жалоба Один из источников полностью программный. Т.е. связка таймер-ПДП-АЦП рулит ШИМ и обеспечивает цифровой ПИД-регулятор. В XMC4xxx можно периферию связывать между собой ещё более аппаратно - даже без использования DMA, который вносит непредсказуемую задержку. Например в текущем проекте у меня передача блока данных по UART запускается сигналом от таймера (аппаратным сигналом без всяких DMA). Это позволяет устройству-приёмнику синхронизировать свои часы с передатчиком с точностью до такта CPU. С DMA такое не сделаешь. Или например: АЦП по нескольким каналам измеряет и суммирует данные с большой скоростью, но пропускает окна из заданного числа тактов вокруг интервалов мёртвого времени от 3-фазного ШИМ (сигналы у переключении ключей на время замораживают АЦП), убирая таким образом из измерений помехи в моменты переключения мощной нагрузки. Да ещё много что возможно. :) Ну да. На самом деле-то вот что интересно: вообще возможно ли сделать так, чтобы "вычислить" начальное место, откуда пошло затирание памяти :rolleyes: Вангую, что нет :biggrin: В общем случае нет, но в части таких случаев - возможно. Нужны соответствующие инструменты. Вот тут коллега haker_fox (вроде?) писал, что работает с LPC43xx. Так в нём есть ETB. Он позволяет сделать обратную отладку. И если со времени первопричины прошло не очень много времени, то так можно найти её. Ну или эмулировать возможности ETB программно: у меня например для этого во многих проектах реализован "Монитор выполнения" - это высокочастотное периодическое прерывание, в котором в FIFO фиксируются регистры CPU и верхушка стека. Он не раз мне тоже помогал находить такие сложные ошибки с разрушением памяти. А вот насчет порчи памяти третьим лицом (функцией в нашем случае) - вещь тоже довольно интересная, случалось сталкиваться с таким А мне даже очень часто случалось сталкиваться. Потому что работаю обычно в команде, и это третье лицо очень часто - один из коллег. Вот это самая засада, когда у тебя начинает глючить совершенно на ровном месте когда ты ничего не менял даже. Просто накосячил один из коллег... :crying: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Arlleex 131 12 июля, 2018 Опубликовано 12 июля, 2018 · Жалоба А мне даже очень часто случалось сталкиваться. Потому что работаю обычно в команде, и это третье лицо очень часто - один из коллег. Вот это самая засада, когда у тебя начинает глючить совершенно на ровном месте когда ты ничего не менял даже. Просто накосячил один из коллег... Вот тут я Вас очень даже понимаю. Бывает над одним проектом работает несколько человек и у каждого "работает все". Про ETB спасибо, кстати, надо бы до конца поразбираться со всякими CoreSight финтиклюшками - ITM, TPIU, ETB (Embedded Trace Bus который) и т.д. А то может уже все придумали давно а мы я не пользуемся(-юсь) :( Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 12 июля, 2018 Опубликовано 12 июля, 2018 · Жалоба ETB (Embedded Trace Bus который) Embedded Trace Buffer Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Kabdim 0 12 июля, 2018 Опубликовано 12 июля, 2018 · Жалоба "вычислить" начальное место, откуда пошло затирание памяти :rolleyes: Вангую, что нет :biggrin: Вычислять нет, разрабатывать так что бы этого не происходило возможно. Использовать Ubsan, например, да и в целом поменьше указателей, побольше контейнеров. Вот только запас по памяти и быстродействию должен быть большим что бы включить и радоваться. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 12 июля, 2018 Опубликовано 12 июля, 2018 · Жалоба Ну никто-ж не спорит, что лучше быть богатым и здоровым чем бедным и больным писать код сразу и без багов. Но что-то ни у кого это не получается. И при компиляции в RELEASE ненайденные баги не исчезают волшебным образом. :laughing: Сдаётся мне, что попытка вытворить такое не уменьшит, а наоборот - увеличит вероятность наличия багов. Вопрос не куда деваются баги, а где и когда их лучше искать. Просто включить логику и осознать целесообразность. При полной неопределенности целесообразней искать там где удобно. А напрягать юзеров и техподдержку логами не имеет смысла. Я на этом обжегся. Во-первых юзеры устраивают истерику когда просишь логи, а тех.поддержка почитав логи начинает косо смотреть и требовать расшифровщик логов для их уровня интеллекта и даже начинают требовать что писать и что не писать в логи. Второе, искать надо там где бОльшая вероятность. И я согласен с ST, что самый чувствительный участок - это RAM. RAM занимает самую большую площадь на чипе. А сбои в RAM-е имеют свойство накапливаться. Поэтому чем чаще тестируете RAM тем меньше накопленных ошибок будет. Ну и последняя модная фишка от IAR 8.20 - стековые канарейки (stack canaries) Такая фича компилера, когда он автоматом вставляет некую проверку стека на целостность в каждую подозрительную функцию. Кста, если кто забыл. Есть еще такая фича у IAR как С-RUN Runtime Checking, тож проверяет кучу косяков в риалтайме как и Ubsan Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
haker_fox 60 13 июля, 2018 Опубликовано 13 июля, 2018 · Жалоба Ну и последняя модная фишка от IAR 8.20 - стековые канарейки (stack canaries) Такая фича компилера, когда он автоматом вставляет некую проверку стека на целостность в каждую подозрительную функцию. Прямо сейчас внедрил в проект этот инструмент. Пусть будет. Вдруг поймает что-то. AlexandrY, я, как понял, вы IAR только используете? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 13 июля, 2018 Опубликовано 13 июля, 2018 · Жалоба Прямо сейчас внедрил в проект этот инструмент. Пусть будет. Вдруг поймает что-то. AlexandrY, я, как понял, вы IAR только используете? Нет не только. Сейчас в активной поддержке у меня проекты в Keil 4, Keil 5, IAR 7 , MPLAB А вот как раз на 8-й IAR я еще не перешел. Жду плагина под MQX. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 13 июля, 2018 Опубликовано 13 июля, 2018 · Жалоба Нет не только. Сейчас в активной поддержке у меня проекты в Keil 4, Keil 5, IAR 7 , MPLAB А вот как раз на 8-й IAR я еще не перешел. Жду плагина под MQX. А что - с 7-го IAR на 8-й надо как-то переходить? :wacko: У меня довольно большой проект нормально компилится и работает как под IAR7.80 так и под IAR8.20. И разницы в работе не заметно. Разве что в размере кода небольшая. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
haker_fox 60 13 июля, 2018 Опубликовано 13 июля, 2018 · Жалоба Жду плагина под MQX. Странно, что NXP купив Freescale не портировал MQX на LPC серию. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Kabdim 0 16 июля, 2018 Опубликовано 16 июля, 2018 · Жалоба Зато они сменили лицензию на 5 версию. За деньги что-нибудь может и будет портировано. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Arlleex 131 17 июля, 2018 Опубликовано 17 июля, 2018 · Жалоба Кстати, коллеги. А нормальная ли практика фиксировать критические события во внутреннюю Program Flash МК? Обычно для внутрисистемных (внутри МК, в смысле) ошибок не требуется много памяти. Выделить два куска по N кБ и цикличный автомат журналирования организовать (чтобы при потере питания последние записи не потерлись). А то я, конечно, сам ставлю на все устройства внешнюю память, но интересует опыт (положительный/отрицательный) журналирования в набортную память МК. ИМХО, если не злоупотреблять printf() с прямым текстом в лог и только регистровые фреймы хранить, самое оно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 17 июля, 2018 Опубликовано 17 июля, 2018 · Жалоба Кстати, коллеги. А нормальная ли практика фиксировать критические события во внутреннюю Program Flash МК? Обычно для внутрисистемных (внутри МК, в смысле) ошибок не требуется много памяти. Выделить два куска по N кБ и цикличный автомат журналирования организовать (чтобы при потере питания последние записи не потерлись). А то я, конечно, сам ставлю на все устройства внешнюю память, но интересует опыт (положительный/отрицательный) журналирования в набортную память МК. ИМХО, если не злоупотреблять printf() с прямым текстом в лог и только регистровые фреймы хранить, самое оно. Расскажите лучше как вы по регистровым фреймам способны хоть что-то понять о причине сбоя. :lol: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aaarrr 63 17 июля, 2018 Опубликовано 17 июля, 2018 · Жалоба А нормальная ли практика фиксировать критические события во внутреннюю Program Flash МК? Не лучший вариант, если принять во внимание сложность реализации и возникающую привязку к железу. EEPROM стоит копейки, ни к чему экономить. Расскажите лучше как вы по регистровым фреймам способны хоть что-то понять о причине сбоя. :lol: Аншлаг прям. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 17 июля, 2018 Опубликовано 17 июля, 2018 · Жалоба А то я, конечно, сам ставлю на все устройства внешнюю память, но интересует опыт (положительный/отрицательный) журналирования в набортную память МК. Во всех устройствах, где надо было вести журналов сбоев, до сих пор располагал его только во FRAM/MRAM. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться