jcxz

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

Только как это помогло бы ТС даже если бы была предусмотрена? Очевидно - никак. Потому как сама процедура подключения отладчика - не мгновенна. И за это время все переходные процессы в страшном "ящике" ТС пройдут. И поведение программы будет совсем другим (чем без отладчика).

Почему "не думать"? Может наоборот "думать" и поэтому лучше каждое минимальное изменение тестировать. Чтобы потом когда написали 100500 строк кода, вдруг не оказалось что где-то глючит, а где - не понятно в той куче изменений. И потом несколько дней отматывать назад - где именно накосячено. Вот именно, что для вас каждое изменение - "перепрошивка". А если отлаживать в ОЗУ её просто нет. И нет проблемы. Сделали простое изменение - сразу протестили. Особенно если что-то непонятно с периферией и приходится исследовать, то бывает и десятки раз перепишешь и перезагрузишь. И что такое "программные брекпоинты" вы видимо тоже в первый раз слышите? Изменение пары строчек в командном файле линкёра для - вас "мозготрах"??? Тогда всё печально. Не представляю как вы вообще что-то программируете. Если такое примитивное действие для вас так сложно. Тётя Клава с рынка - тоже не затёрла ни одного. А всё почему? Просто потому, что никогда не программировала ничего. PS: И ещё один плюс отладки в ОЗУ - из-за того, что всё размещение кода-данных полностью перетряхивается (в другое распределение памяти), то могут вылазить скрытые баги (например с разрушением памяти). Которые иначе не были бы выявлены. Чтобы что-то осмысленно измерять, нужно хотя-бы примерно представлять что делает какая часть вашего кода. Иначе грош цена таким измерениям.

Всего каких-то 10тыс. циклов. При 100 стираниях в день хватит на ~100 дней. А 100 стираний в день при активной отладке и программных брекпоинтах во флешь - вполне реально. Или больше (с программными бряками - может значительно больше). Что-то не верится... Разве что у вас совсем маленький код. Обычно даже загрузка в ОЗУ занимает несколько секунд. Всё вместе. Кто "она"? И почему "грузится"? Что и куда грузится? LwIP - это часть программы. Грузится эта часть в память МК отладчиком при загрузке вместе с остальным кодом. Но выше вы писали что у вас всё ПО грузится миллисекунды. А тут оказывается только одна часть ПО - уже 2 секунды. Что-то путаетесь совсем.... PS: LwIP-ом не пользуюсь. У меня свой стек.

Вполне вероятно. Но похоже наш ТС не из тех, кто ищет проблему у себя.

Вам нужны практики? Практики ищутся в разделе "Предлагаю работу". Для тех кто сам не может её сделать. Сбой где? В чужом оборудовании? Тогда почему ищется не производителем этого оборудования? В вашем программе? Тогда при чём тут "чужое оборудование"? Тут большая часть программистов на форуме работает с "чужим оборудованием". Которое тоже включается и стартует. Но это никак не мешает им отлаживать работу с ним. Известная тема. Кто не смог отладить у себя на столе или в лаборатории, тот потом отлаживает "в поле". Вы здесь ищите того, кто вам их открутит? Или к чему эта сентенция вообще? Наймите гастарбайтера, который будет вам их откручивать. К чему эти причитания вообще? Вы думаете вы один, кто работает с такими устройствами? Цель вашего поста какова? Пофлеймить? Найти работника, который отладит вашу программу и выловит все баги, коих там наплодили? или...?

Какую именно "инфраструктуру"? Периферию МК? Так она точно так же инитится и по обычному сбросу. Который можете подать без выкл.питания. Если у вас проблема с её инитом - так подавайте сброс на МК и отлаживайте J-Link-ом без выкл.питания. Ничто не мешает поставить бряк на начало кода (хоть сразу на вектор сброса) и подать reset на МК. Если же проблемы во внешних (относительно МК) компонентах, то непонятно - как тут поможет инициализация периферии эмулятором? Если проблемы в работе вашей программы с внешними компонентами сразу после старта, то можете запитать МК отдельно от остальной схемы; подключиться к нему эмулятором (остановив исполнение на каком-то датчике наличия внешнего питания); а потом подать питание на внешние компоненты, запустив таким образом и исполнение программы. Но конечно могут быть проблемы с паразитной запиткой этих внешних компонентов от сигналов МК. PS: Имхо - основной инструмент отладки программы, это не эмулятор, а голова программиста. Она и должна позволять локализовать проблему, а потом решать её. Выбирая наиболее подходящие инструменты. Если проблема например - в каких-то невыдерживаемых вашей программой времянках обращения к внешним компонентам после вкл.питания, то эмулятор тут вообще никак не поможет. Так что - не эмулятор дрессировать нужно, а свою схему изучать и даташиты на компоненты. И думать.

Отлаживать код в ОЗУ МК. Что и гораздо быстрее и не тратит ресурс флешь и в принципе не грозит такими сюрпризами, какой случился у вас.

А можно и не делать Erase All. А просто подтянуть и ... дальше так и продолжать отлаживать в ОЗУ. PS: В который уже раз поражаюсь людям, отлаживающим код во флешь контроллера, имеющего на борту аж 1376 КБ жирнейшего ОЗУ! Это примерно то же самое, что имея дома электрическое освещение, продолжать пользоваться свечками и керосинками.

Тогда писать во внутреннюю FLASH. Хоть по 32 бита - без разницы. PS: Если есть батарейка (питающая RTC-блок памяти (даже без часов)), то может проще в этой памяти хранить счётчик. Выдернули батарейку - потеряли аренду.

Да уж... Как всегда - начали за здравие, а закончили за упокой. Поставьте мелкую FRAM. А чтобы не считали - вроде как само собой разумеющимся будет - шифровать её содержимое. PS: Вроде ещё в самом начале сами же писали, что "знаете про AES и т.п". А получается, что не знаете. Раз такие глупые вопросы задаёте. PPS: Вангую - следующий вопрос будет: "Как писать во FRAM, чтобы не бояться внезапных выключений питания?"

Тем что нет никакого "пути доступа DMA1 к DTCM". На вашем же рисунке всё написано. Неужто так сложно его прочитать? Что такое "Master interface" и "Slave interface" - понимаете? Где на вашей картинке обозначения "Master", а где "Slave" - видите? Почему доступ может идти только по пути: "Master" -> "Slave" - понимаете? Это примерно то же самое, что в электронике вход логического элемента и его выход. Понимаете почему нельзя соединять два выхода лог.элементов? Вот и здесь примерно то же самое. Ну или примерно то же самое как две части разъёма: "папа" и "мама". И почему нельзя воткнуть "папу" в "папу"? (хотя в нонешние времена это уже могут подвергнуть сомнению; особенно в некоторых странах )

Это с чего сделан такой странный вывод?? Вроде по рисунку чётко видно, что DTCM подключена только к ядру. Как можно умудриться так извращённо понять его?... Вот уж и вправду говорят: "Даже если ваше объяснение настолько ясно, что исключает всякое ложное толкование, все равно найдется как минимум один человек, который поймет его неправильно". По этой диаграмме любой благоразумный человек поймёт - что с чем работает. Уж насколько нужно вывернуть мозг, чтобы понять её неверно. Подобные диаграммы есть в мануале практически каждого контроллера. Читаются они везде одинаково. Неужто вы их ни разу раньше не видели?

Нельзя. Кроме простых кодов для входа в инет-банк (которые да - подобны старой кодовой карте), он генерит и ещё коды типа2. Я выше писал об этом (только почему-то никто из отвечающих не читает - о чём идёт разговор): Для кодов типа2 аргументом является код, выданный на странице инет-банка. Все расходные операции подтверждаются именно так. И тут последовательность похожа на то, что хочет ТС.

Сравните вручную файлы JLinkARM.dll в папке сеггера и в папке Кейла. Возможно не хватает прав и нужно заменять файлы вручную. Или может Кейл не закрылся. Тогда он естественно заблокирует .dll. Проверить через Диспетчер задач. Конечно он должен .dll менять в папке Кейла. Я по-моему уже несколько раз это сказал.

И что? Причём тут постоянный пароль??? Вы умеете в уме генерить пароли? И выполнять AES-шифрование? А смартфон нельзя потерять или сломать? Похоже голова у вас совсем не включается. Печально.... Если бы умели включать, то догадались бы что: 1. Пенсионеры - тоже люди 2. Не на любой смартфон поставится ваше приложение. Если смартфон рутованный - облом. Если смартфон не с самой последней версией OS - тоже облом.

Ещё раз: Проблема не в прошивке J-Link-а. Потому как с моим J-Link Ultra .dll-ка v6.94 - не работает (выдаётся такое же окошко как у вас), а старая .dll v6.12f - работает отлично. Версию прошивки J-Link на обоих скриншотах видите? Она одна и та же. J-Link - один и тот же. И IAR - один и тот же. Но с верхним драйвером - работает, с нижним - нет. Выводы можете сделать? У меня на работе до вчерашнего утра тоже - в IAR-е стояли дрова сеггера v6.94. JetLink с которым работал - работал с ними нормально. Вчера принесли другой JetLink (чуть более старый) - он с v6.94 стал выдавать такое же окошко, как у вас. Парой кликов заменил .dll на v6.12f - окошко выскакивать перестало. Т.е. - всё то же что у вас. Только всё заняло пару минут, а не несколько дней трёпа на форуме. Выводы? Я тоже не ставил. и что?

А если попробовать включить голову? Из внешнего вида и цены видно, что девайсы фабричные, изготавливаемые серийно. И скорей всего - крупносерийно (при такой цене). К тому же - несколько разных моделей и производителей. Значит - пользуются спросом. Причём тут "помнить пароль"??? Девайс генерит одноразовые пароли. Вы даже не понимаете что делает этот девайс, но уже делаете вывод "ненужное уг". Как неандерталец, который то же самое сказал бы, увидев смартфон. Сейчас вам будут приводить ссылки на всяческие мутные ресурсы. Как доказательство... Но вот сколько здесь на форуме не поднималось тем про взлом (а было их ой как много), что-то не припомню где приводились бы не вызывающие сомнения доказательства успешного взлома: Название девайса, прошивку которого удалось вскрыть, его схема, сама прошивка и т.п. Чтобы можно было проверить. Все утверждения на уровне - ОБС (одна бабка сказала).

Почему "разъедется"? Куда? У меня на рабочем компе стоят несколько версия дров сеггера. Меняются между собой в отладчике они за пять секунд несколькими кликами. Впрочем - дело ваше. Всяк суслик сам себе агроном. И на каком основании сделан такой вывод?

А что мешает установить период сброса в несколько нсек? За несколько нсек тоже схема сгорит??? PS: Да и кстати - в нормальных контроллерах защиту принято делать ещё и аппаратную. Не надеясь полностью на программную. Для этого даже в таймерах МК есть вход TRAP (или FAULT). А если у вас система так сделана, что её палит установка бряка, то вообще в мусорку такую схему. Так как бряк может устанавливаться во флешь, и тогда никакими микросекундами там и близко не пахнет. Как минимум - несколько мсек.

Не знаю можно ли сделать такое в STM32, но в XMC4xxx я бы просто запустил второй таймер, не останавливаемый отладчиком. Который бы сбрасывался периодическими событиями от вашего останавливаемого таймера, а когда таких событий нет - его счётчик добегал бы до некоего конечного значения переполнения (или COMPARE-события). Дальше просто проверяем флаг наличия переполнения - есть значит останов скорее всего был. Ну или запустите любой таймер (хоть внутренний WDT, который только генерит не сброс, а прерывание). И периодически его сбрасывайте по COMPARE-событию (часто сбрасывайте). Если добежал до переполнения, значит -> не было сброса -> был останов. Это будет весьма сложно сделать с остановленным CPU. Ведь ТСу явно это нужно знать в программе.

Кодовый калькулятор, о котором писал выше - это видимо и есть такой аппаратный генератор лицензий. Их существует множество готовых. Только на странице Swedbank-а вижу несколько штук разных: https://www.swedbank.lv/business/d2d/ebanking/authentication?language=RUS (раздел "Калькулятор кодов"). И купить и использовать его может видимо кто угодно, не только банки. Стоят они как видно - сравнительно недорого = 6-12 евро. И разрабатывают и производят их не сами банки видимо, а сторонний производитель. Значит устройство его известно не только пользователю (банку).

Ну-ну.... Так почему тогда до сих пор не сломали кодовый калькулятор Swedbank-а? Ведь там, за этим взломом, такой жирный куш маячит! В виде миллионов евро на счетах юзеров. Ломай и греби бабки лопатой! Имха - все эти россказни про лёгкий взлом разных МК, по большей части - байки. Да, в каких-то МК видимо были баги, которые и позволяли их взламывать. Конкретно эти семейства МК. Но это скорее частные случаи, чем правило. Иначе такие устройства, как этот самый кодовый калькулятор, были бы просто невозможны. Так как легко ломались бы.

При том, что например в нашем Swedbank-е доступ к инет-банку может открываться генерацией кода кодовым калькулятором. Это такое небольшое устройства, формата брелока, в котором видимо стоит защищённый каким-то образом МК. Если ломать МК так легко, как вы рассказываете, то эти брелоки должны ломаться на раз. И кто угодно может легко получить доступ к любому чужому счёту. Но почему тогда не происходит массового взлома счетов??? PS: Кстати - этот кодовый калькулятор работает примерно так же (такой же порядок действий с ним), как хочет чтоб работал генератор кодов аренды ТС. Например для выполнения какой-то расходной операции по счёту: страничка инет-банка генерит код; этот код вводится юзером в калькулятор; калькулятор в ответ генерит код-ответ; который затем вводится на инет-странице для подтверждения операции. Примерно то же самое хочет ТС, только инет-страничку и девайс поменять местами.

Результат - мотор сдох, рельс остался недопиленным. Так как в пиле был PMSM-мотор. Который не поедет без участия контроллера. Пример со счётчиком - тоже мимо кассы (если конечно счётчик сделан толково). Никакой нормальный интеллектуальный счётчик не станет считать в обратку. Не надо слушать сказки для простаков. Чем умнее и сложнее техника, тем меньше с ней работает метод лома и кувалды. ну да, ну да... свежо предание, да верится с трудом... Если вас послушать, то диву даёшься - и как только всякие интернет-банки работают??? Ведь любой школопет должен одной левой их ломать. И все защиты в контроллерах - тоже конечно ничего не стоят.