Flashing a new bootloader via serial bootloader (rev3)

LeafLabs Garden » Development

Flashing a new bootloader via serial bootloader (rev3)

(15 posts) (4 voices)

Started 3 months ago by bnewbold
Latest reply from poslathian

Tags:

No tags yet.

bnewbold
Key Master
Notice that shiny new button on the opposite side of the maple from the reset button? It's fun for the whole family (on GPIO pin 38), but also moonlights as a BOOT control pin: when the button is pushed when the STM32 is reset or powered on, the microprocessor enters a hardware bootloader mode which listens on USART1 for upload data. This is a hardcoded, low level bootloader, not to be confused with maple-bootloader which listens on the USB port and accepts uploads over DFU from the IDE or dfu-util. What this method is most useful for is upgrading or replacing maple-bootloader itself!

To flash a new bootloader over serial, you'll need a means of serial communication (we usually use a USB-Serial FTDI chip), a .bin file of the bootloader you want to upload (you can compile the latest version of ours using the source from http://github.com/leaflabs/maple-bootloader ), python (including the PySerial library), and the modified version stm32loader.py script from the micromouse project (the original was written by Ivan A-R: http://tuxotronic.org/wiki/projects/stm32loader ):

http://www.micromouseonline.com/blog/2009/05/07/stm32-arm-cortex-bootloader

The procedure I use on linux is to first connect both the FTDI chip and the Maple to my laptop via USB, power them on, and connect the GND, RX, and TX pins to the Maple on USART port #1 (pins 7 and 8, not 0 and 1). I make sure that the FTDI chip shows up as a device on my system, usually as /dev/ttyUSB0. Then I hold down the BUT button and press RESET on the Maple; after a second or two I release the BUT. The LED should not power up when in the serial bootloadermode. Then I go to the root of my Maple bootloader (where I have stm32loader.py extracted) and run:
```
./stm32loader.py -p /dev/ttyUSB0 -evw build/maple_boot.bin
```
You may have to replace /dev/ttyUSB0 with your platform's serial device and build/maple_boot.bin with the path to the actual .bin youwant to upload.

If it works you'll see a bunch of upload/verify memory addresses scroll by. If it doesn't work, make sure you entered the serial bootloader mode correctly, that your RX/TX lines aren't swapped, that all the devices are powered on, and that you have appropriate permissions for your serial port.

Happy hacking!
Posted 3 months ago #
zhanx
Member

Can we add this to the v 1.o boards?

Posted 3 months ago #
bnewbold
Key Master

The rev1 boards have the same microcontroller so this should definitely be possible. Let me check the circuit schematic and see what we did with the BOOT pin on that design; it may require manually cutting a trace on the board.

It's busy around here and might be a day or two before I post a result; if you're impatient you can look at the STM32 reference manual and track down the exact pin: http://www.st.com/stonline/products/literature/rm/13902.pdf

Posted 3 months ago #
bnewbold
Key Master
Success! I just got this to work with a rev1 board and an FTDI chip without cutting any traces. A slightly tweaked version of the bootloader is required to actually upload programs (see bottom). You can download a .bin file from http://static.leaflabs.com/pub/leaflabs/maple-bootloader/maple_boot-rev3-8b4cea-rev1-mods.bin

We left the BOOT0 pin floating in rev1 (floating pins are often a no-no but was a suggested option in this case), so all that needs to be done is apply 3.3v to to the BOOT0 pin, which is number 60 out of 64 (1-indexed; see Figure 5: STM32F103xx performance line LQFP64 pinout in this datasheet: http://www.st.com/stonline/products/literature/ds/13586.pdf ). The pin is TINY, but the pins on either side are boring GPIO which you can safely apply 3.3v to (as long as you don't have user code running which configures them as, eg, open drain), so you can kind of fudge this procedure. I used a jumper wire from Vcc to the appropriate pin (5th from the dotted corner along the side of the stm32 closest to the JTAG connector and USB port). Touch the pin, press and release reset, wait a second, then release the pin; the status LED should not be blinking if the chip is in serial bootloader mode. Then follow the above directions.

Here's a low resolution photo just so you can get a rough idea of the procedure: http://www.flickr.com/photos/48069758@N08/4648490702/

I was able to flash the bootloader using the above technique and then reprogram using the latest IDE. There may very well be issues using the latest libmaple with the older hardware... for example the analog and external pins won't match the silkscreen and if I recall some PWM pins got remapped and won't work as expected.

The required bootloader modification was to /not/ check if the boot button gets pressed later in the boot process, which would cause the bootloader to run indefinately (see http://leaflabs.com/docs/maple-bootloader ). The patch against main.c in maple-bootloader is as simple as:
```
<br />
   /* wait for host to upload program or halt bootloader */<br />
-  bool no_user_jump = !checkUserCode(USER_CODE_FLASH) && !checkUserCode(USER_CODE_RAM) || readPin(BUTTON_BANK,BUTTON);<br />
+  bool no_user_jump = !checkUserCode(USER_CODE_FLASH) && !checkUserCode(USER_CODE_RAM);<br />
```
Posted 3 months ago #
zhanx
Member

you rock!

Posted 3 months ago #
poslathian
Key Master

should we infer that as a successful report from the field? heh.

Posted 3 months ago #
beckel
Member

I just got this to work and I now have my customized bootloader on the chip. I just wanted to note that it took me a while to get the chip into serial bootloader mode. The problem was that I was holding down BUT, then just tapping RESET. I didn't get it to work until I held down BUT, then I held down RESET for a few seconds. Maybe I wasn't fully resetting the device? Not sure, just a caveat...

BTW, Thanks for the instructions. This built in serial bootloader is awesome!

Posted 3 months ago #
bnewbold
Key Master

Awesome! What customization did you do? Just speed up that huge delay? ;)

Difficulties noted, i'll add to the documentation. I think the flux remover we used to clean up the boards may have damaged some buttons, though we did test every board that went out. We'll use a different technique in the future.

Posted 3 months ago #
zhanx
Member

poslathian you know me, always out there tinkering with stuff. Of course i got it.

Posted 3 months ago #
beckel
Member

Yes, I changed BOOTLOADER_WAIT in config.h to 30 (b/c I am on still on a VM and having some issues). I also changed line 50 in main.c from:

while ((delay_count++ < BOOTLOADER_WAIT) || no_user_jump) {

to:

while ((delay_count++ < BOOTLOADER_WAIT || no_user_jump) && !readPin(BUTTON_BANK, BUTTON)) {

That way, when I come back from a reset performed by the IDE, I can hit BUT to jump to user code instead of waiting for the 30 pin strobes.

In messing with this configuration, I think I realized that my BUT button is acting strange, electrically speaking. First off, the serial bootloader still takes many tries to catch. I have to hold the BUT button and then repeatedly hit the reset until I see the LED stop. I also noticed that the time it takes for my code to jump out of that modified while loop is intermittent (while hitting the BUT I mean). Sometimes it works, sometimes it doesn't. I think the only thing that can cause these 2 behaviors is a bad connection somewhere in the BUT path. I haven't pulled out any tools to verify this but it seems to be the simplest answer.

Posted 3 months ago #
bnewbold
Key Master

Nice!

That's horrible about the button; our testing procedure for every button on every board was to verify by pressing hard and holding for about a second. It's definitely possible to not-quite-push it if you're in a rush, but it sounds like you're giving it a good go and not getting results. If you think it's a problem with the button we can definitely ship you replacement buttons or figure out how to get your board fixed for you. Other than a multimeter, you can try testing the digital state of the button and spitting it back over the serial ('r' mode in the interactive test program, though in the default floating input modes most of the pins will be flipping like crazy!).

Posted 3 months ago #
beckel
Member

It is definitely the button that is broken and not the board. I put my multimeter across it using the continuity setting and pushing the button yielded no sound. Doing the same procedure with the RESET button worked as expected.

Posted 3 months ago #
poslathian
Key Master

Beckel, we're sending you a new button correct? We tried out something new to clean up the boards before we shipped them. The method didnt get along well with the button rubber. We checked all the buttons (and replaced quite a few) on the boards that went out, but I guess yours slipped by. Sorry! Get in touch with us via email if you need a new button!

Posted 3 months ago #
beckel
Member

Yes I talked to Bryan over email the other day. He said he was shipping me a new button.

Posted 3 months ago #
poslathian
Key Master

Great!

(there was no need for me to post here, but i needed to clear the thread with a LL person as the last poster...our tech support strategy in action!)

Posted 3 months ago #

RSS feed for this topic

Reply

You must log in to post.