Serial-only USB boot loader

STM32duino bootloader aka Maple bootloader
jcw
Posts: 171
Joined: Mon Oct 26, 2015 8:16 am

Re: Serial-only USB boot loader

Post by jcw » Wed Nov 11, 2015 2:12 pm

Looks like ARM builds aren't quite working yet. I'm trying this on a Nucleo F103:

Code: Select all

[stm32f1init] boot-usbSerial-v01.h

(When you see a question mark: RESET your TARGET board!)

  Connecting? . OK
 FAILED - got 0x1F
Code on GitHub has been updated. One of the issues was figuring out the Nucleo serial port numbering, which appears different from the other boards, see https://github.com/jeelabs/embello/blob ... no#L22-L28

Has anyone verified that the SERIAL_8E1 option for USARTs works on F103s? Putting the h/w in even-parity mode, that is.

User avatar
Rick Kimball
Posts: 1038
Joined: Tue Apr 28, 2015 1:26 am
Location: Eastern NC, US
Contact:

Re: Serial-only USB boot loader

Post by Rick Kimball » Wed Nov 11, 2015 4:42 pm

Instead of having the user press buttons, could the sketch toggle the BOOT0 and the Reset pins itself?
Last edited by Rick Kimball on Wed Nov 11, 2015 5:02 pm, edited 1 time in total.
-rick

jcw
Posts: 171
Joined: Mon Oct 26, 2015 8:16 am

Re: Serial-only USB boot loader

Post by jcw » Wed Nov 11, 2015 4:59 pm

I'd expect stm32f1init to be for mostly-one-time use, but sure.

Just to confirm: the sketch pulls B0 low, toggles reset down briefly, uploads, pull B0 high, and toggles reset again to start the target?
I can probably manage that :) - it needs two more wires and matching documentation, but their use can remain optional.

User avatar
Rick Kimball
Posts: 1038
Joined: Tue Apr 28, 2015 1:26 am
Location: Eastern NC, US
Contact:

Re: Serial-only USB boot loader

Post by Rick Kimball » Wed Nov 11, 2015 5:05 pm

jcw wrote:I'd expect stm32f1init to be for mostly-one-time use, but sure.

Just to confirm: the sketch pulls B0 low, toggles reset down briefly, uploads, pull B0 high, and toggles reset again to start the target?
I can probably manage that :) - it needs two more wires and matching documentation, but their use can remain optional.
Yes, I think so.

I don't think it matters what happens to B0 after reset has happened I don't think it looks at it again.

The reason I ask about the auto mode, is because I think I can get this stuff to work on an msp430g2 launchpad. However, It would be easier to disable the debug serial output and just blink the leds to indicate progress and success or failure. That way I could use the one hardware serial port to talk to the stm32f1 device.

-rick
-rick

jcw
Posts: 171
Joined: Mon Oct 26, 2015 8:16 am

Re: Serial-only USB boot loader

Post by jcw » Wed Nov 11, 2015 5:27 pm

MSP430G2553, I presume? That's not much RAM. Would be neat though. Yes, LEDs would be useful too.

User avatar
Rick Kimball
Posts: 1038
Joined: Tue Apr 28, 2015 1:26 am
Location: Eastern NC, US
Contact:

Re: Serial-only USB boot loader

Post by Rick Kimball » Wed Nov 11, 2015 5:49 pm

jcw wrote:MSP430G2553, I presume? That's not much RAM. Would be neat though. Yes, LEDs would be useful too.
Yes, that is it. Don't need much ram. Seems to compile into less than 12k with the usb serial bootloader.
-rick

jcw
Posts: 171
Joined: Mon Oct 26, 2015 8:16 am

Re: Serial-only USB boot loader

Post by jcw » Wed Nov 11, 2015 6:09 pm

Great, I've added a LED option and the ISP + RESET control lines. Latest in GitHub.
Will be happy to add support for MSP to this, just submit a pull request.

Edit - LED blink rate, on ATmega: 0.25 Hz = trying to connect, 1 Hz = programming, 5 Hz = error, steady = done.

User avatar
Rick Kimball
Posts: 1038
Joined: Tue Apr 28, 2015 1:26 am
Location: Eastern NC, US
Contact:

Re: Serial-only USB boot loader

Post by Rick Kimball » Wed Nov 11, 2015 6:25 pm

How about abstracting out the Log code...
#ifdef __MSP430__
#define Target Serial
#define LED_PIN P1_6
#define RESET_PIN P1_5
#define ISP_PIN P1_4
#define Log_begin(s)
#define Log_print(s)
#define Log_println(arg1, ...)
#define Log_flush()
#elif ARDUINO_STM_NUCLEO_F103RB
#define Log Serial1
#define Target Serial
... implement real logging to second device
#else
#define Log Serial
#define Target Serial1
... implement real logging to second device
#endif
-rick

jcw
Posts: 171
Joined: Mon Oct 26, 2015 8:16 am

Re: Serial-only USB boot loader

Post by jcw » Thu Nov 12, 2015 1:14 am

First commit of the USB serial uploader is now here: https://github.com/jeelabs/embello/tree ... s/usbserup
Needs a small change to stm32flash, to be submitted as PR on GitHub later.

This needs an extra entry in boards.txt (can be avoided by moving the boot loader to high flash, but that's a bit more work).
The current code emulates a minimal subset of STM's USART upload protocol, i.e. compatible with F1's ROM boot loader.
If this gets replaced with an avrdude-STK500 mode, then stm32flash & patch would not be needed anymore.

jcw
Posts: 171
Joined: Mon Oct 26, 2015 8:16 am

Re: Serial-only USB boot loader

Post by jcw » Sat Nov 14, 2015 9:30 am

The build instructions for usbserup have changed. You no longer need an old copy of libopencm3, see README.

Reflecting a bit on all the little details to make this new boot loader practical, here are the key TODO's, I think:

* switch to the STK500 protocol, so uploads can be done with avrdude
* put the boot code in high-flash, so sketches can be loaded at 0x08000000, as usual
* listen to DTR and RTS low, to act as self-reset request (if possible, need to investigate)
* find a way for the loaded sketch to re-use the open serial connection

That last one is actually optional. With a sketch which simply re-inits the USB device, things already work. And if that sketch also includes the logic to listen to DTR+RTS, then it would be able to self-reset just like the Maple boot loader does. No more button pressing, which was one of the goals for all this.

With the above changes, a new upload method needs to be added, called "Serial (avrdude)". Since the load offset will be gone, the same code can then also be uploaded using Serial, ST-Link, or BMP. The only difference in the IDE is which TRANSPORT is used to get the code into the µC. This will make build settings and upload settings independent (orthogonal).

There's an interesting feature in avrdude to connect to a remote network port and upload the sketch there. Maybe one day we can get that going as well. I've been using socket-based uploads in other contexts, and in fact the "esp-link" (https://github.com/jeelabs/esp-link) project also supports it.

Post Reply