How to program flash directly thru SWD?

[paul0208]

Hi, Everyone,

I am developing the standalone SWD programmer operating by battery.

I have a problem to program flash thru SWD directly.

So, I traced SWD line with the ST-Link Utility.

It looks that some tiny flash program code and updated user firmware are store to RAM.

After than, flash program in RAM is running and writing the downloaded user code in RAM to flash. Is it right?

Why ST-link utility use this mechanism, not using direct writing to flash?

How to write the data onto flash directly?

According to the reference manual, half-word should be write... How to send half-word?

SWD protocol use 32 bit operation AFAIK.

BR

Paul

[Uwe Bonnes]

Here the code from bl*ckm*g*c:

void firmware_mem_write_sized(ADIv5_AP_t *ap, uint32_t dest, const void *src,

                                                       size_t len, enum align align)

{

       uint32_t odest = dest;

       len >>= align;

       ap_mem_access_setup(ap, dest, align);

       while (len--) {

               uint32_t tmp = 0;

               /* Pack data into correct data lane */

               switch (align) {

               case ALIGN_BYTE:

                       tmp = ((uint32_t)*(uint8_t *)src) << ((dest & 3) << 3);

                       break;

               case ALIGN_HALFWORD:

                       tmp = ((uint32_t)*(uint16_t *)src) << ((dest & 2) << 3);

                       break;

               case ALIGN_DWORD:

               case ALIGN_WORD:

                       tmp = *(uint32_t *)src;

                       break;

               }

               src = (uint8_t *)src + (1 << align);

               dest += (1 << align);

               adiv5_dp_low_access(ap->dp, ADIV5_LOW_WRITE, ADIV5_AP_DRW, tmp);

               /* Check for 10 bit address overflow */

               if ((dest ^ odest) & 0xfffffc00) {

                       odest = dest;

                       adiv5_dp_low_access(ap->dp,

                                       ADIV5_LOW_WRITE, ADIV5_AP_TAR, dest);

               }

       }

}

[paul0208]

Thank you, Uwe,

Hard to read the code :)

It is for SWD protocol?

SWD protocol is using 32-bit operation.

In case of half-word write, I wonder that sending 16-bits data only or right or left adjusted 32-bits.

ST_link utility always do 32-bits write/read to target in my trace.

BR

Paul

[Andreas Bolsch]

Flash programming requires in some way or the other polling several status flags repeatedly. If the programming adapter (ST-Link, JTAG-adapter, ...) is connected to host (where the actual programming software resides) by a slow (regarding round-trip time) protocol like USB, Ethernet, the programming would be incredible slow. For a few bytes this doesn't matter that much, but for 2 MBytes (or even 64 MBytes for an external flash) it does.

So the preferred method is to squeeze only the payload through this communication channel with as little acknowledging as possible into a simple buffer in the target mcu, and let this mcu drain from thios buffer and do all the bit manupulation *simultaneously* with the transfer.

Further advantage: the transfer to the buffer and the communication with the target does not depend on the particular mcu family. Only the flash loader (the program downloaded into the target's RAM) depends on the mcu family.

[paul0208]

Thank you, Andreas,

I understand you.

But, speed is not concerned with me. just wonder how to write the flash thru SWD

My hardware is connected to the target thru GPIO acting SWDIO/SWCLK/SWRST.

I want to develop the standalone flash programmer, not using DFU, IAP ..., using SWD protocol.

I did the reading MCUID, erase flash, ... by SWD protocol thru GPIO, ... but flash programming is fail....

BR

Paul.

[Andreas Bolsch]

Well, if you've already implemented memory reads and writes via SWD, then flash prgramming is not going to cause trouble.

Regarding halfword accesses: "C2.2.5 Variable access size for memory accesses" in "ARM Debug Interface Architecture Specification ADIv5.0 to ADIv5.2" explains how to accomplish halfword and byte memory accesses. Although this is designated as optional, I'm pretty sure ST's Cortex-M all do support these extensions.

[S.Ma]

Go to arm documentation about swd and the hw debug ip and how it works first to all cortex M.

I would guess the hw emu ip can controlbthe core and read write memory space. The look at flasg hw spec and registers in mcu reference manual and find out how to program it.

I think there are some online source code for swd and debugger code... Just do some digging.

[S.Ma]

Otherwise an st link tied to a laptop fits the bill i think....

[S.Ma]

If you want electrical isolation, an stlink v2 with usb isolator or stlink opto iso version voids battery need.

Bootloader enables flash programming through i2c usart and spi or usb... Much simpler

[paul0208]

Finally, I use Raspberry Pi installed openocd with ST-Link