MIK32 AMUR on ELBEAR ACE-UNO board from ELRON, my experience or how to load Blink for three days

Hello everyone! ✋

Finally, the long-awaited one came to me MIK32 AMUR on the board ELBEAR ACE-UNO from ELRON. I had to tinker with it quite a bit, at some point I thought they had sent me a “brick”, but it turned out there were just some nuances that I'll tell you about now.

For those who don't know MIK32 AMUR – it is a K1948VK018 microcontroller from Mikron. It is the first fully domestic MK, developed and manufactured in Russia. The difficulties I had with it – they are only either due to haste or lack of knowledge, which I want to share with you in this article.

So, the microcontroller did not want to be detected for a long time. From the very beginning, “for some reason” PlatformIO did not work, the MIK32 library was not detected and an error popped up. Now I know that I simply did not read carefully instructionsbut then I couldn't install it, and you should pay attention to the links in the instructions wiki.mik32.ru and do everything exactly as described there, do not rush (:

Then I installed MicronIDEbut openOCD wrote an error, saying that nothing was connected to JTAG. More precisely, the error was first given by the Micron uploader, and it in turn addressed openOCD.

The error initially looked like this:

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

Then I installed SyntacoreIDEbut the same error appeared with it. I then began to try to start AMUR through the console, following the example from video Ruslana from the channel FabmicroLLC. I remade the Makefile for myself since he was flashing AMUR under Linux, but I work under Win10.

A new error has been added to the first one:

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

If you have a similar error in “mik32_upload.py”, in the “upload_file” function, then pay attention to the order in which you have specified the flags, I had them at first like Ruslan:

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

It turns out that in Win10 mik32_upload complains if the firmware file is specified after the flags, this error disappeared after I moved the firmware file before the flags:

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

But this did not save me from the JTAG error. Somewhere on the third day of torment and futile ATTEMPTS I read in the datasheet that when 3.3v is supplied to BOOT0 the MK boots from RAM, and when 3.3v is supplied to BOOT1 it boots from flash memory. By default it boots from EEPROM memory and I assumed that something happens at the moment of startup and that is why the MK does not respond.

Having put a jumper on BOOT0 and launched openOCD via the console, the MC responded for the first time. As it became clear now, something was written to the EEPROM memory, which prevented openOCD from launching. Having booted from RAM, I was able to write an example of FreeRTOS operation to flash via SyntacoreIDE (the first thing that came to hand), and then for testing I wrote a regular blink.

In theory, BOOTLOADER was written to EEPROM memory, since by writing to flash and rebooting the MK without a jumper, AMUR did what I wrote. After practicing with blink, I flashed this example to EEPROM memory and after that I was able to do further flashing without a jumper on BOOT0.

Thus, now, when writing to flash memory, the firmware did not change anything, since the firmware that was written to EEPROM worked. Having found an example of a bootloader in MikronIDE, I edited it, added my Makefile and wrote it to EEPROM. Now I can easily flash the flash without a jumper and everything works as expected.

While I was writing this article ELRON, in my telegram sent a link to yours GitHub where they posted their version BOOTLOADER'a And UPLOADER'awith which you can flash the MK via USB. I checked, everything works great and very fast – the difference in the speed of loading into flash is simply huge.

First, compile the elbear_fw_bootloader.hex file or take the ready-made one from the releases. Then load it into the EEPROM via the programmer. And then assemble elbear_uploader.exe or take the ready-made one from the releases and flash the MK with the command:

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

Specify your COM port of course and compile the downloaded firmware with spifi.ld to load it into flash.

Something like that.

I posted a video with my impressions on my YouTube channel Farmer.

Here is the link on my examples of blink, bootloader and more. Little by little I add examples, now I tested I2C and SPI.

Glory to Our Gods and Ancestors!!! ✋