Bootloader for Generic STM32?

I read in the Arduino forum that the Maple bootloader doesn’t work on generic STM32 boards due a little hardware difference.

I wonder if it is possible to implement a bootloader like the one in the little Digispark.

I’m not sure what DigiSpark uses for its bootloader.

There is an interesting page on the Leaflabs site about the bootloader about why they ended up needing special hardware.
http://leaflabs.com/docs/bootloader.html

However I agree that if we can make a bootloader that doesn’t need additional hardware, it would open things up.

I note there is “Serial” branch of the original Maple bootloader, but I not know what that does, or if it worked.

Anyway, the Digispark bootloader is worth looking at

Edit

I’ve taken a quick look at the Digispark bootloader, and basically its a USB implementation for AVR chips that don’t have native support for USB.

The STM32 is a bit different, and is more like the Arduino Leonardo, or ProMicro

I know there were a lot of issues its the Leonardo bootloader, as it used to confuse Windows into allocating more and more COM port numbers to the same board.

So I think there are pitfalls with this method that would need to be avoided.

I don’t know if this would work, but perhaps a bootloader could be written, which appears as the same USB serial device as the sketch, and implements the processor side of the STM32 flash protocol.
Because we could then use the existing STM32flash uploader binaries e.g. stm32flash.exe

The trick however is when the bootloader hands over to the USB serial code in the sketch, because this would need to be done in such a way as the host doesn’t notice the change.
Which is possibly where the Leonardo bootloader has issues.

We could do a fairly simple test of the basics of this approach

In the existing bootloader source, change the USB VID and PID numbers etc to that of the Serial device.
Then just let just put in a delay, before jumping to a sketch that is built for Maple mini , which has the USB serial code in it

However this may not work, as I suspect the init code from the USB Serial in the sketch would need to be removed

A more radical approach of removing the USB serial code from the sketch is another option, and get the bootloader to always handle all serial traffic

But there must have been a reason why Leaflabs didn’t do this ?

Perhaps they had invested too much time in DFU uploads, or thought that high speed uploads via DFU were essential to the Maple and Maple line of products.

Unfortunately Marti from Leaflabs is busy doing other things, and I doubt he has the time to explain the decisions made at the time they first due developed the bootloader and the boards and libmaple ( which must have been a massive task)

I just do wonder one thing.
If the MCU can be rebooted by software, why do they need to pull the reset line? why don’t just do a software reset?
Is the reset vector changed during sketc runtime? even then, the serial routine that monitors the serial port and trips the reset line could, instead of pulling a line down, write the reset vector with the hardware default reset address, and call a reset.
No need for special hardware…

Victor

I’m not sure how the code resets the processor. I thought it was via software, in which case I agree an external line is not needed.

I’d need to double check if thats really the case

I know that the little ATTiny doesn’t have a native bootloader.
Digispark bootloader creates a virtual serial port but if it don’t receives any command in five seconds then it destroys the virtual serial port and starts the sketch loaded, if there is one. The drawback is that a sketch takes five seconds to start.

Anyway this is a solution for lazy people like me since the serial bootloader works well and I have an STlink clone also.

A bootloader for Generic boards would be great. But its something for the future. Perhaps I need to make a sticky

I still have some bug fixing to do on “Bootloader 2.0” to get 100% backwards compatibility with the old version.

Currently uploads to Ram don’t work Well, it uploads to Ram but then doesn’t run the RAM version. I think I have a solution for this, but setting up the forum has taken up more time than I realised it would over the last couple of days, so Bootloader 2.0 has had to wait.

Hopefully I can spend some time on it at the weekend.

zoomx wrote:I know that the little ATTiny doesn’t have a native bootloader.
Digispark bootloader creates a virtual serial port but if it don’t receives any command in five seconds then it destroys the virtual serial port and starts the sketch loaded, if there is one. The drawback is that a sketch takes five seconds to start.
Anyway this is a solution for lazy people like me since the serial bootloader works well and I have an STlink clone also.

@Roger,
I believe that the bootloader 2.0 for Maple has the priority, as I wrote serial upload isn’t too bad.

@mrburnette
My idea is not to use a V-USB but the hardware USB, if it is possible to activate a bootloader for five seconds or another trick. Maybe it is difficult, Maple team added some hardware stuff because of this?

Guys

The code to support USB Serial is part of the libmaple core, we don’t need V-USB as the existing code works well already

Serial USB can now be compiled for generic boards using the -DSERIAL_USB define in the compiler flags, so that after a hard boot the generic board behaves like a Maple mini after the bootloader has handed control to the sketch

I will need to write an announcement to explain this in more detail, as there are some caveats.

To make a Serial bootloader however, the serial code from libmaple would need to be copied to the bootloader, and in reality we’d copy the code from Bootloader 2.0 and replace significant portions of it with serial code from the core. I suspect it may end up being bigger than the current version as the serial code may be bigger then the DFU code.

I will try to find time to write, a tutorial or perhaps do screen capture video on how to install MinGW on windows so that people can start participating in the Bootloader development

I don’t find bootloaders sexy at all, why?
1: Boot delay for every code
2. Messing around with buttons/resets
3. separate driver (ok, doesn’t bother me, I not on Windows, but many other people) This would be a new situation for Windows 10,11,12 I say only “signed drivers”
4. The “hitting the right time the “serial monitor” button because I miss something”-syndrom: On USB-TTL converter, FTDI or ST-link you can easily let the com port open and don’t think about it.
5. Less RAM (ok, some bytes)

zoomx wrote:Anyway this is a solution for lazy people like me since the serial bootloader works well and I have an STlink clone also.

I took a look at the “Serial Bootloader” branch of the original bootloader,

See https://github.com/jonatanolofsson/mapl … erial-boot

There is a very interesting description of how the was going to be the new bootloader for the Maple boards, but its unclear why they stopped development

It looks like it could be a good basis for a generic bootloader, as a lot of the code is already written (though I don’t know if it works at all)

I think we should also move this thread into the Bootloader section, and rename the section “Bootloaders” and have separate threads for the current DFU based bootloader and possibly a new generic / Serial based bootloader