Qmk_firmware: ISP Flashing Guide for ARM boards

[drashna]

Like the title says.

You can get ST-LINK flashers for like $4, so no need to "hack" one together.

But we need an actual guide on how to do this, as well as links to bootloaders for the ARM chips.

Also, @patrickmt, if you have any input/information on this?

[yiancar]

Correction, its not called an ISP rather its called SWD (single wire debug) and it is ARM generalized. (ie almost any sensible vendor with an ARM core would use it).

That being said, SWD is only the way to move data in and out (like JTAG) the actual boot sequence can be complex and weird depending on the device.

STM32s support a \variety of boot modes (https://www.st.com/content/ccc/resource/technical/document/application_note/b9/9b/16/3a/12/1e/40/0c/CD00167594.pdf/files/CD00167594.pdf/jcr:content/translations/en.CD00167594.pdf). Here you can see UART, I2C, SPI and others.

By default ST programs a bootloader in system memory. Which kind of bootloader depends on the part number of your device (https://www.st.com/content/ccc/resource/technical/document/reference_manual/4a/19/6e/18/9d/92/43/32/DM00043574.pdf/files/DM00043574.pdf/jcr:content/translations/en.DM00043574.pdf page 63). System memory cannot be erased or altered by the user. Therefor whatever happens there is always a way to flash the device as long as boot0 and boot1 pins are configured correctly. As a result using a part number with a USB DFU bootloader solves most problems.

Now lets say the user wants to use another bootloader for whatever reason. This can be done the same way as AVR. There are some open source bootloaders (example https://github.com/devanlai/dapboot), however this means that the firmware should be shifted by the size of the bootloader. This can be done by the chibios linker script which by default assumes it can start from the beginning of flash memory.

Back to the ST-LINK. The user can load a firmware in flash using a gui or cli tool provided my ST (https://www.st.com/en/development-tools/stsw-link004.html). This tool can also be found in brew or similar.

So to summarize:
Regarding STM32s.

• All STM32s come with a bootloader in system memory which is non erasable.
• Depending on your exact part number, the bootloader might be UART, DFU, SPI, I2C.
• This simplifies everything if you select a part number with DFU.
• ST-LINK can use the debug interface to load your firmware into flash (like ISP would do).
• Other bootloaders can be used but firmware location must be adjusted.
• My recommendation, use a part number with DFU bootloader as its a bulletproof method!
• This way you never need an ST-LINK, except if you actually want to use the debugger.

[yiancar]

How does this work for the atmel arm @patrickmt ? I think from the ST side just putting somewhere in the docs that you should be careful to select the correct part number that should be ok. ST doesnt actually release a binary for preprogramed bootloaders. So the only option if you make a mistake on the part number would be to create a huge mess by offsetting the firmware and downloading a volatile opensource bootloader

[patrickmt]

My experience with programming ARM based Atmel (now Microchip) SAM MCUs is through the Atmel-ICE development tool. In conjunction with Atmel's atprogram utility (included with Atmel Studio), this is used to program the bootloader on Massdrop's keyboards (CTRL and ALT for example) at the factory using ARM's SWD (Serial Wire Debug) configuration. The SWD interface comprises a clock line, a single data line, reset line, 3.3V, and ground, reducing the number of lines needed compared to JTAG.

Atmel-ICE User Guide
ARM SWD Information
Atmel Studio

I haven't done research on alternative programmers if there are any.

The bootloader being loaded is a modified version of Atmel's SAM-BA. It occupies the first 16K of flash memory, with free space allocated for future modification, leaving 240K program space with the current ATSAMD51J18A MCU.

When using atprogram, you can write to any portion of FLASH. It is important to specify the offset address when sending firmware as to avoid overwriting the bootloader. Using the information stated above, firmware should be set to load at address 0x4000 (16K) and must not exceed 0x3C000 (240K) in size. A typical command would look like:

atprogram.exe --tool atmelice --interface SWD --device ATSAMD51J18A --verbose --clock 2mhz program --offset 0x4000 --verify -f firmware.bin

When programming over USB, the bootloader provides read access of all memory as well as write access to RAM. A separate program, called an applet, is compiled with details about the device and methods to read/write FLASH memory. This applet is loaded into RAM through the bootloader and does the actual programming of the FLASH when loading firmware. Although it is possible for an applet to write to the bootloader section of FLASH, the current applet has safeguards in place to prevent this and communication utilities should also do the same.

It is up to the utility communicating with the bootloader to determine the correct applet to send. For example, mdloader will query the MCU for its chip ID located at a specific address. This chip ID is then matched against supported IDs. The applet can provide information, such as its version and memory settings, and be used to verify additional settings before proceeding.

Currently, the best way to obtain the bootloader running on a keyboard is to read the first 16K bytes of memory into a file. This can be done through mdloader as follows:

mdloader.exe --first --upload btl.bin --addr 0x0 --size 0x4000

[yiancar]

Ok so probably for ATSAM it si worth detailing this/ along with a link to the bootloader you use?

[yiancar]

Also if people are looking for a more generalized arm orogramer j-link / sagger ones are the way to go. They come at that price tho:)

[drashna]

@yiancar well, for now, I think we need instructions for the STM32 chips that we're using, as well as ATSAM stuff.

Aka, for the boards we support.

[yiancar]

The STM32 chips we are using now are the variant with dfu bootloader already in system memory. So are you talking about how to get them in bootloader mode? Other than that there is nothing more needed to program an stm32 device. They are made like this for upgrdability in the field.

ST link is nothing more than a j-link debugger configured for stm microelectronics. This is the beauty of the ARM ecosystem:)

[yiancar]

Any more work i cn do on this?