Friday, 17 September 2010

Converting the STM32 to Boot Mode.

As with the ST8 Discovery board we have super hardware and lousy software support. Things are better now in that the demos actually work, but the software choices are annoying (silly screens) or limited (only 32k of code). The bug that was in the ST8 Discovery board (half working USB memory interface) isn't fixed either.

So, we have to access the hardware differently. In this case, we will use the GNU Compiler, and the STM32's inbuilt bootloader.

(Some lessons have been learnt from the ST8 Discovery - the STM32 is much easier to prototype, as you can plug it straight into a breadboard - except for the bottom rows (PB0-PB15). I struggle to believe that particular piece of design, but I can get round it by hanging it off the bottom of the breadboard)

The first thing we have to do is to set up the board so when it resets it goes into "BOOTLOADER" mode.

Table 1 of the Bootloader Document (AN2606) tells us this :

BOOT1 BOOT0 Boot Mode
X     0     User Flash memory    User Flash memory is selected as the boot space
0     1     System memory        System memory is selected as the boot space
1     1     Embedded SRAM        Embedded SRAM is selected as the boot space


So to get it to work we need to get BOOT1 to Logic 0 and BOOT0 to Logic 1

Returning to the STM32 Discovery guide, we see that these are set by solder bridges.

Bridge SB2 (BOOT1) is currently set to Ground (Logic 0) via a pull down resistor, which is correct. However, Bridge SB16 (BOOT0) is also connected to Ground (Logic 0) via a pull down resistor so that "User Flash Memory" is selected.

Moving on to Figure 11 (the schematic) we can see that removing SB16 will indeed push BOOT0 to Logic 1.

Not a good solution though, really. My "fix" for this is to put a 220R resistor between "Boot" (actually Boot0) and 5v on the top Right Hand side of the board.  Thus mangling the potential divider.

Changing the circuitry to enable boot mode
The dotted line and associated resistor has been added.  We can more or less ignore the minimal current passing through the 10k resistor, and as a potential divider the voltage on BOOT0 is 510 / (510+220) * 5 v, which is 3.49v, slightly above Vcc, but within tolerances - and that pin is 5v tolerant anyway, according to the specification.

On my board it actually reads slightly less than this, but near enough.

You can this works by putting the 220R* resistor between lines "5V" and "Boot". If you now press reset the demo program the STM32 comes with (flashing the green led and the blue one if you press the button) doesn't start up. If you remove the resistor, then it works again.

There's a fair amount of current coming down here (6ma) that isn't necessary, but as the board is powered by the USB port, it doesn't matter - I think.

I am rather making this up as I go along. (There's a chance this might never work at all), so all suggestions or criticism are welcome.  Nothing is put on the blog until it is actually tried for real though.

NOTE: Following some discussions I reckon a 270R resistor may be better than a 220R. While it works fine on my board, the voltage is may be a little high ?

6 comments:

  1. Hello. Many thanks for these tutorials. There is one thing I don't undestand though. Could you please elaborate on the "half working USB memory interface"? Is that why the board doesnt show up in /dev as a ttyUSB but somehow works in Windows?

    ReplyDelete
  2. Hi. There's something wrong in the implementation of the USB Memory interface (it pretends to be a USB Memory stick) which causes it to continually reset under Linux. On my machine (Ubuntu 10.04) it will eventually show up as a folder on the desktop, but dmesg shows it messes around a lot in the process.

    This seems to be the exact same problem as its predecessor the STM8 Discovery board had. Someone investigated it, and apparently it's just bad coding - it works well enough to run on Windows, but won't work on anything else.

    The refusal to show up as /dev/ttyUSB0 is infuriating :( This appears to be a deliberate decision by ST. If it did, then all the hardware (except the BOOT0 resistor) could be dumped.

    ReplyDelete
  3. Hi,

    Can you please tell my, WHY we have to solder an extra resistor to the board? I read the manual and I think, that it should be enaught, wenn I just remove the resistor on the solder bridge S16?!

    I did that and I can program the STM32, but every time I repower or reset it, I have to reflash the Board, is that the reason why?


    Greez

    ReplyDelete
    Replies
    1. In answer to your question, you don't. I'm using a breadboard which the devboard plugs into.

      The aim was (i) make it easy for non-solderers to do and (ii) allow the board to be returned to "out of box" state without having to solder the link back in.

      Delete
  4. Nowadays you can also use this code to program through gdb:
    https://github.com/texane/stlink

    The newest version doesn't work for me though, try this one:
    https://github.com/whitequark/stlink/commit/d1c3176f3a7cdbd7a0c4df832c627bc508a75296

    ReplyDelete
  5. Thanks for very interesting information!

    For compile cut -Werror in build/Makefile,

    for example/build.sh:
    CHAIN=/usr/bin/arm-elf
    PATH=/usr/bin/arm-elf/bin:$PATH
    or you path to arm-elf toolchain,

    add to gcc options
    -Wl,--section-start=.text=0x8000000 \ #for flash
    or
    -Wl,--section-start=.text=0x20000000 \ #for SRAM
    and read README.

    It Works!

    ReplyDelete