st-flash and STM32F0

[trsaunders]

I'm trying to use st-flash to flash the STM32F0 discovery. Here's what happens:

tom@Z77A-GD65:~/projects/rc/src/syncf0$ st-flash write build/ch.bin 0x08000000
2012-06-07T17:19:46 INFO src/stlink-common.c: Loading device parameters....
2012-06-07T17:19:46 INFO src/stlink-common.c: Device connected is: F0 device, id 0x20006440
2012-06-07T17:19:46 INFO src/stlink-common.c: SRAM size: 0x2000 bytes (8 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 1024 bytes
2012-06-07T17:19:46 INFO src/stlink-common.c: Attempting to write 28488 (0x6f48) bytes to stm32 address: 134217728 (0x8000000)
2012-06-07T17:19:46 WARN src/stlink-common.c: unknown coreid: bb11477
2012-06-07T17:19:46 WARN src/stlink-common.c: Failed to erase_flash_page(0x8000000) == -1
stlink_fwrite_flash() == -1

[szczys]

I'm planning to work on this issue but won't have time until the end of the upcoming week. I believe this is the same problem as Issue #88.

[UweBonnes]

The F0 has a reduces instruvction set. OpenOCD has a seperate loader for the F0. Maybe we need a seperate F0 loader too?

[szczys]

It looks like all of the flash unlocking/erasing/writing functions already use if/else tests to adjust for the two different methods used by earlier boards. We can probably just use the Programming Manual to roll in the commands needed for this board..... but it'll take a while.

Eventually all of this should be abstracted out into a different file so that we don't need to do this each time someone wants to add support for new hardware.

[trsaunders]

I had a go at implementing this myself and got as far as the flash loader. Where is the OpenOCD flash loader for F0? I couldn't see it in http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=tree;f=contrib/loaders/flash;h=88b7884ee9c3608eb167b7f9006fa28020322ab9;hb=HEAD

[UweBonnes]

There is a aptch for openocd to review at http://openocd.zylin.com/604

[szczys]

I just finished digging into the STM32F05x reference manual (RM0091) to compare register and bit addresses for the flash control module. This may end up being easier than I thought. It looks like all the registers, offsets, and bits are the same. The two differences are the size of the register (this may not matter?) and it seems this chip doesn't use the RDPTR_KEY.

Here is my diff file FYI- https://gist.github.com/2907339

[szczys]

It looks to me like OpenOCD uses loader code for Cortex-M0 chips through the stm32f1x.S file ( view it here ). Can anyone tell me if this is already implemented in stlink and if not, is there anyone who can translate it for use with the write_loader_to_sram() function?

[UweBonnes]

I didn't notice that anybody implemented it. You write the code into the loader_code_stm32[xx] array and perhaps adapt for different parameters in th usersof that code.

[szczys]

I've figured that much out. But I don't know what I'm doing when it comes to the loader code. So far I can get it to unlock and erase the flash, but it bombs out in that 1000 cycle loop when trying to launch the loader code (I was trying to use the STM32VL values there).

Not sure where to go from here.

[szczys]

I'm at a dead end on this one. I can't get the flash loader from OpenOCD to work. If someone would like to lend a hand I've committed a VERY messy branch here:

https://github.com/szczys/stlink/tree/f0-flash-loader-testing

[UweBonnes]

Go away for some time. Come back to the code later. I then normally clap at my head, fix an obvious error and things start to work. I am away for the next week, and F0 is not high on my agenda, so no help from my side that soon.

[pekkanikander]

Maybe I'm missing something altogether, but to me it looks like that the assembly code does not read the buffer in SRAM and store it to the flash, but it assumes that someone else is writing to an FIFO-area pointed by r2.

Hence, to me it looks like that the assembly code in the patch simply cannot work, as it doesn't assume the flashed binary to be in the SRAM as the calling code assumes.

But I'm quite new to this, so I need to have a much better look to understand what's going on.

[UweBonnes]

"Pekka" == Pekka Nikander notifications@github.com writes:

Pekka> Maybe I'm missing something altogether, but to me it looks like
Pekka> that the assembly code does not read the buffer in SRAM and store
Pekka> it to the flash, but it assumes that someone else is writing to
Pekka> an FIFO-area pointed by r2.  Hence, to me it looks like that the
Pekka> assembly code in the patch simply cannot work, as it doesn't
Pekka> assume the flashed binary to be in the SRAM as the calling code
Pekka> assumes.

Pekka> But I'm quite new to this, so I need to have a much better look
Pekka> to understand what's going on.

I think nobody looked at the F0 so long. It probaly needs some work. The F0
is not high on mu agenda, so don't expect any contribution from me.

Bye

Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

[pekkanikander]

I have made now some progress with STM32F05x. Firstly, it looks like the flash controller in the STM32F05x is similar to the flash controller in STM32VL, which has the STM32F100RB MCU, a Cortex-M3 based MCU. From the outset, the registers etc look similar. So, I have basically enabled STM32VL functionality also for the STM32F05x. At the moment, the code seems to recognise the ship and correctly erase the flash.

However, I enter problems with the SRAM-based flash routine. The one for STM32VL will not work, as it uses instructions that are not available in Cortex-M0, e.g. the post-increment stores and loads. Hence, I wrote a replacement, using the STM32VL routine and the ST AN4065 code as the bases. No problem with that.

However, I have serious problems when I try to actually execute the loader code in the SRAM. Initially the code went into a loop and the MCU never halted. After that, I made a very simple loader that has just a single bkpt instruction. That also never halted. Then I made a program that had two bkpt instructions; it worked. The processor did halt, but non-surprisingly the later code in stlink_common.c:run_flash_loader fails, as the r2 value has not been changed.

As a third attempt, I wrote a very simple "pseudo"-loader, as below:

        0x00, 0x30, //     nop     /* add r0,#0 */
        0x00, 0x22, //     mov     r2, #0
        0x00, 0xBE, //     bkpt #0x00

This does halt, but the register r2 still does not change.

So, I'm starting to wonder if the stlink-usb.c:_stlink_usb_read_reg would need to be modified somehow?

I also don't understand why the single-breakpoint program doesn't halt, but the two breakpoint one does? Could there be endianness problems, as I'm using a Mac?

Any ideas how to continue?

[pekkanikander]

For some reason the STM32F0 Thumb1 SRAM-flasher code needed two NOPs in the beginning. With them it works, or at least seems to work. And apparently also sometimes without them, sometimes. I don't understand what's going, though, so I'll leave the NOPs there into the code, with a proper comment.

Anyway, I seem to have the STM32F05x support, for STM32F0-discovery, now working. I have now committed it to our fork. However, I won't make pull request just quite not yet, as I want to test this first a little so that there aren't any remaining bugs.

If you want to have a look before that, here it is: https://github.com/Senseg/stlink/commits/master

[karlp]

Pekka: I got your branch working, but it needs lots of reset button presses. I'm only testing with a single page blinky right now anyway, but it is at least working somewhat! Just needs tidying up!

[pekkanikander]

Thanks, Karl. I have been busy with other stuff this week, but should have time to continue with the stlink from Monday or Tuesday. If you have any suggestions what to do, please let me know. Or feel free to tidy up yourself and make the pull request from your fork.

[pekkanikander]

I have now tested our code quite a lot. It has two deficiencies. Firstly, I have to first "st-link erase" before doing "st-link flash", otherwise the discovery boards goes to some weird state. Secondly, it doesn't boot the newly flashed image, but the reset button has to be pressed for that. But if I first erase the flash, then flash, and then reset manually, it works well enough.

As I'm not inclined to work more on this at the moment, I'll create a pull request.

[xor-gate]

Should be fixed by now.