I am trying to program an STM32F0 from a linux based processor. I have connections to the SWRST, SWDIO and SWCLK pins.

I have most of it working well, but when I go to write to the flash memory locations, it fails with the DAP controller reponding with ACK FAIL. My current technique is to access the flash memory controller registers @0x4002200 and to write to flash this way. Just like the flash programming examples in the STM32 datasheet

I have verified that I am able to erase flash. When I capture some traffic from my ST Link programming the part, it seems to use a very different approach that i can't figure out, it seems to be writing to addresses @0x20000000. My flash is @ 0x08000000.

Does anybody have experience with this? Is my approach completely wrong?

  • \$\begingroup\$ I'm not 100 % sure, so no answer, but I guess they load a program to RAM which does the flashing and they shovel the data to be written into the RAM as well (sequentially calling the flashing routine). But I can be completely wrong on this. \$\endgroup\$ – Arsenal Jun 30 at 14:40
  • \$\begingroup\$ I recommend you learn to program the flash by writing a program in ram to do it (load_image myprog.elf then resume 0x20000000 (needs a different bootstrap entry than a reset)). But yes you should be able at least with that part family to poke at the registers one at a time and erase then write. The newer parts with security dont necessarily work as they filter based on who is trying to write to what when and what is enabled as to whether you can do it. I think I could only run through a ram based program to do what I was trying to do. \$\endgroup\$ – old_timer Jun 30 at 15:15
  • \$\begingroup\$ as answered the stlink tools did/do send some code over to run in ram in the background, faster/cleaner, than trying to poke registers one at a time via swd. I tend to write my own program so that it works on any debugger, software to write to flash plus the data as well and any usable debugger can copy that to ram and start it. That or make a bootloader then interact via uart with it. \$\endgroup\$ – old_timer Jun 30 at 15:17
  • \$\begingroup\$ these parts have a factory bootloader that you can talk to via uart, etc and not use swd at all, pretty easy to use. \$\endgroup\$ – old_timer Jun 30 at 15:17
  • \$\begingroup\$ swrst not generally needed, just swdio and swclk at a minimum is enough to program (non-bricked) parts. \$\endgroup\$ – old_timer Jun 30 at 15:18

The flash is not directly programmed via SWD.

First a piece of MCU code, a loader stub that can program FLASH, is loaded via SWD to SRAM.

Then the data that needs to be programmed is transferred to SRAM via SWD.

Finally the CPU is told to jump and execute the programming code and it does the programming.

This way you can program to any internal or external memory, as long as you have a compatible loader stub.

If you need to program MCU firmware from Linux, just execute a program that does it for you.

| improve this answer | |
  • \$\begingroup\$ Thank you, that explains it. But do you have any idea why my method fails and gives ACK fail as soon as I write to flash locations? Is there some lock that I am missing ( I have done the flash unlock sequence) and I can erase successfully already \$\endgroup\$ – Eoin O Connell Jun 30 at 15:12
  • \$\begingroup\$ It is not correct. You can flash it but for the performance reasons small programs written to RAM are used. \$\endgroup\$ – P__J__ Jul 1 at 19:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.