Привет всем! Меня зовут Евгений и я работаю программистом микроконтроллеров в компании Бастион г. Ростов-на-Дону.
В своих проектах мы очень часто используем STM32F030 как сопроцессор отвечающий за реалтайм задачи (АЦП, обработка кнопок, управление дисплеем), а вот бизнесс логику выносим на контроллеры помощнее. В процесе работы естественно стал вопрос с выпуском обновлений программ для устройств и о том как обновлять ПО и на нашем «сопроцессоре» (фига себе сопроцессоры у нас, конечно, но вот такие термины). Так как с основным процессором мы связаны по UART, то сюда, как нельзя лучше, подошел UniversalBootLoader (UBL), который уже есть во всех процессорах STM.
Рассказ о том как прошивать сами контроллеры через UBL уже есть на сайтах многих эмбедеров (easyelectronics.ru и istarik.ru разжевывали эту тему не раз), но у меня появился отличный сайдквест.
Сейчас совсем немного контекста, для понимания с чем я столкнулся.
Для стирания памяти через UBL в STM32 есть алгоритм который представлен ниже
Во всех инструкциях на сайтах и в примерах даташитов от STM32 для стирания памяти используют команду массового стирания памяти (по левой ветке) путем посылки команды FF FF, реже чистят по банкам памяти, но очень мало кто дает примеры очистки определенных станиц памяти.
В проектах на F030 мы очень часто экономим деньги на установку EEPROM и используем самописную библиотеку для реализации EERPOM in Flash, путем выделения пары страниц в конце флеша для работы с этими страницами как с EEPROM. И вот в последнем проекте мы столкнулись с использованием этой либы в «сопроцессоре» и тем что мы теряем все данные из нашего EEPROM после перепрошивки.
Посмотрели настройки прошивки — все правильно на две страницы меньше размер и прошивка заливается как должна. И тут я понял, что мы используем MassErase и именно он стирает всю память. А почему собственно и не должен.
Открыв даташит AN3155 я начал пробовать сделать стирание по алгоритму из левой ветки (стирание по страницам).
Общий смысл команды простой. Отправляем код команды 0x44 с CRC 0xbb. Получаем от контроллера ответ что он воспринял 0x79(символ «y» в ASCII) Дальше пишем сколько страниц хотим стереть, перечисляем все наши страницы и добавляем CRC. После этого должны получить ACK (0x79) от контроллера.
Попробовал отправить
И тишина!!! Контроллер просто чего то еще ожидает… Проверил CRC два раза )) Проверил посылку, скорость, биты и все все все…
Отчаялся решить проблему в лоб и достал макетку и логический анализатор. Подключился к макетке через CubeProg через UART и встал на подслушку анализатором.
Попробовал стереть теже самые 3 страницы.
Естественно все стерлось. Начал смотреть что там захватил и очень удивился. Оказывается количество страниц указывается N-1. Хотя во всех даташитах указано либо N, либо вообще N+1…
Решил проверить свою теорию стерев 4 страницы. Все подтвердилось и контроллер радостно вернул ACK через 70мс.
Дальше я решил, что 4х страниц мне не хватит и решил стереть всю память программы 126 страниц. Записал, что нужно стереть 125 страниц и перечислил 126 страниц. и получил кракозябры от контроллера. Хотел бы сказать что удивился, но уже нет. Снова берем Макетку, CubeProg и анализатор сигнала. Снова запускаем задачу стереть все 126 страниц в CubeProg. Снова захватываем сигнал и видим:
CubeProg стер 100 страниц (99 в счетчике) и затем оставшиеся 26 страниц (25 в счетчике) Занавес. Опять подстава.
Походил поудивлялся. Добавил к себе в алгоритм все эти особенности и вуаля! Оно работает и стирает все кроме нашего EEPROM in Flash.
Вот такая вот подстава от казалось бы именитого производителя STM32. И даже не одна, а целых две.
Хотел бы еще раз напомнить все начинающим эмбедерам, что:
Логический анализатор — это друг эмбедера с большой буквы!!! Если бы не он, то понять, что там твориться было бы практически невозможно.
P.S: Пост написал с целью самому интересно и вам показать. На пулицеровскую не претендую ))).
ссылка на оригинал статьи https://habr.com/ru/articles/892550/
Добавить комментарий