Здравствуйте все! ✋

Наконец-то ко мне пришёл долгожданный MIK32 АМУР на плате ELBEAR ACE-UNO от ELRON. Нормально так мне с ним пришлось по возиться, в какой-то момент уже подумал что прислали "кирпич", оказалось просто есть кое-какие нюансы о которых я сейчас расскажу.

Кто не знает MIK32 АМУР - это микроконтроллер К1948ВК018 от фирмы Микрон. Это первый полностью отечественный МК, разработанный и произведённый в России. Сложности, которые у меня с ним возникли - они только либо из-за спешки, либо из-за недостатка знаний, которыми я в этой статье и хочу с вами поделиться.

Итак, микроконтроллер долгое время у меня не хотел определяться. С самого начала "почему-то" не заработал PlatformIO, библиотека MIK32 не определялась и выскакивала ошибка. Теперь то я знаю что просто невнимательно прочёл инструкцию, но тогда не смог установить, а вы в инструкции обратите внимание на ссылки wiki.mik32.ru и сделайте всё в точности как там описано, не спешите (:

Потом я установил MikronIDE, но openOCD писал ошибку, мол к JTAG ничего не подключено. Точнее ошибку сначала выдавал uploader Микрона, а он в свою очередь обращался к openOCD.

Ошибка сначала выглядела так:

Error: JTAG scan chain interrogation failed: all ones
Error: Check JTAG interface, timings, target power, etc.
Error: Trying to use configured scan chain anyway...
Error: riscv.cpu: IR capture error; saw 0x1f not 0x01

Тогда я установил SyntacoreIDE, но и с ним появилась та же ошибка. Я тогда уже через консоль стал пробовать завести АМУР, по примеру из видео Руслана с канала FabmicroLLC. Переделал Makefile под себя так как он под Linux'ом прошивал АМУР, я же работаю под Win10.

К первой ошибке добавилась новая:

Traceback (most recent call last):
File "E:\GitFlic\C_study\MIK_c\AMUR\libs\mik32-uploader\mik32_upload.py", line 431, in
upload_file(
File "E:\GitFlic\C_study\MIK_c\AMUR\libs\mik32-uploader\mik32_upload.py", line 241, in upload_file
openocd.run(f"adapter speed {adapter_speed}")
File "E:\GitFlic\C_study\MIK_c\AMUR\libs\mik32-uploader\tclrpc.py", line 106, in run
reply = self.sendrecv(wrap)
^^^^^^^^^^^^^^^^^^^
File "E:\GitFlic\C_study\MIK_c\AMUR\libs\mik32-uploader\tclrpc.py", line 74, in sendrecv
self.sock.sendall(data)
OSError: [WinError 10057] Запрос на отправку или получение данных (when sending on a datagram socket using a sendto call) no address was supplied

Если у вас возникнет подобная ошибка в "mik32_upload.py", в функции "upload_file", то обратите внимание на то в какой последовательности у вас указаны флаги, у меня они сначала были как и у Руслана:

python mik32_upload.py --run-openocd --openocd-exec=$('путь_до_openocd') --openocd-interface=$('путь_до_m-link.cfg') --openocd-target=$('путь_до_mik32.cfg') build/firmware.hex

Получается что в Win10 mik32_upload ругается если файл прошивки указывать после флагов, эта ошибка исчезла после того как я переставил файл прошивки перед флагами:

python mik32_upload.py build/firmware.hex --run-openocd --openocd-exec=$('путь до openocd') --openocd-interface=$('путь до m-link.cfg') --openocd-target=$('путь до mik32.cfg')

Но это не избавило меня от ошибки JTAG'а. Где-то на третий день мучений и тщетных поПЫТОК я прочитал в даташите что при подаче 3.3в на BOOT0 МК грузится с оперативной памяти, а при 3.3в на BOOT1 грузится с флеш памяти. По умолчанию же он грузится с EEPROM памяти и я предположил что именно в момент запуска что-то происходит и поэтому МК не отзывается.

Поставив перемычку на BOOT0 и запустив openOCD через консоль МК впервые отозвался. Как стало ясно теперь в EEPROM память было что-то записано, что мешало запуску openOCD. Загрузившись из оперативной памяти я через SyntacoreIDE смог во флеш записать пример работы FreeRTOS (первое что попалось под руку), а далее для тестов записал обычный блинк.

По идее в EEPROM память был записан BOOTLOADER, так как записывая во флеш и перезагружая МК без перемычки, АМУР выполнял то что я записывал. Потренировавшись с blink'ом я прошил этот пример в EEPROM память и после этого дальнейшую прошивку я смог делать уже без перемычки на BOOT0.

Таким образом, записывая во флеш память прошивку ничего не менялось, так как работала та прошивка, которая была записана в EEPROM. Найдя пример бутлоадера в MikronIDE, я его подредактировал добавил свой Makefile и записал его в EEPROM. Теперь я спокойно без перемычки прошиваю флеш и всё работает как положено.

Пока писал эту статью, ELRON у себя в телеграме скинули ссылку на свой GitHub где они выложили свой вариант BOOTLOADER'а и UPLOADER'а, с помощью которых можно прошивать МК по USB. Проверил, всё работает отлично и ооочень быстро - по скорости загрузки во флеш разница просто огромная.

Сначала скомпилируйте elbear_fw_bootloader.hex файл или возьмите в релизах уже готовый. Потом загрузите его в EEPROM через программатор. А далее соберите elbear_uploader.exe или возьмите в релизах уже готовый и прошейте МК командой:

elbear_uploader.exe build/firmware.hex --com=COM3

Укажите свой COM порт конечно же и загружаемую прошивку скомпилируйте с spifi.ld что бы загружать её во флеш.

Вот как-то так.

Видео с впечатлениями я выложил на свой Ютуб-канал ХуторянинЪ.

Вот ссылка на мои примеры blink'а, bootloader'а и не только. Помаленьку добавляю примеров, сейчас тестировал I2C и SPI.

Слава Наша Богам и Предкам!!! ✋