Can I make a custom Bootloader for stm32f051

Question

I am new to this bootloader stuff. I program stm3205 using SWD. So In which location does my program goes when I program stm32f05 microcontroller. Can I make my own Bootloader and replace it with st's default bootloader.

I dont think you can replace ST's bootloader, but you can absolutely make your own. No reason why you couldnt (okay well maybe some platforms you cant in application program other portions of flash. But so far all the stm32's I have tried you can). — old_timer
Its all right there in the st documentation. Maybe you can replace the bootloader, just have to read up on it. Neither SWD nor using their bootloader tells us where you have put your program nor how you run it. You can load your program into ram with SWD and run it there. If your program runs on power up then you have put it where the documentation says to put it. Its in the docs. — old_timer

old_timer old_timer · Accepted Answer · 2016-07-07T04:09:53

I would disagree with the word difficult. A bootloader is a fairly simple program to write, much simpler than most microcontroller applications.

The logic uses the boot0 and maybe another strap to determine whether to boot the internal st bootloader or boot the application. This is documented in the reference manual as well. I searched for boot0 and went right to it in the second chapter. Dont be surprised if your chip does not have a boot1 pin. From the boot modes table basically boot0 is deciding to boot from the st bootloader in rom/flash or your application in flash.

Im not going to re-read the whole document for you. But the memory map shows the flash at 0x08000000 that is where your programs will start. Being a cortex-m (see arm architectural reference materials which maybe st has a version or definitely arm supplies, also the technical reference manual). The cortex-m uses a vector table of addresses, so if/when you build your program correctly it will start with the preload of the stack pointer then the address to your reset vector (lsbit set to indicate thumb mode, but if you do all of this right the toolchain will take care of that) which will be ideally in the 0x08000000+offset area. With boot0 strapped to ground (zero) it boots from main flash memory, basically 0x08000000 is mapped to address zero for the core processor. But your vector table basically makes it jump to main flash for execution.

The same section on boot modes shows system memory with boot0 is a 1 (tied high) and that the st bootloader is in system memory and which usart pins to use for serial loading. Some other st document describes the serial loader, it is a fairly simple program to write on the host to interface with this loader to erase and/or download programs into the main flash memory. No doubt there are countless already written programs out there. But depending on how you design your bootloader you might need a host program to implement that side of your protocol. Either way it is an afternoons project to interface the st bootloader and a good skill to have in your back pocket for this type of work.

You of course have to figure out how to enable the peripherals like the uart and the gpio. Good idea to start with blinking an led then using that with learning how to use a timer to figure out what clocks are really being used when your program is in control so you can set the uart right and get it running. Best to start by allowing programs to be downloaded to ram and then branch to them and cover that half of the bootloader task, then deal with the writing something to flash task. Best to use the uart as at least your first bootloader user interface. Stock dumb terminal programs can speak xmodem and can/should be able to dump raw files down as well. So with my bootloaders I used to do xmodem which a quick and dirty state machine was dozens of lines of code. But I now either use intel hex or better motorola srecord, I like the srecord with full 32 bit addresses per line, by far the easiest of the bunch. As with xmodem, only takes a few dozen lines of code to handle the incoming stream of text (intel hex or srecord if you choose one of those) parse it and write what comes in to ram at the right address. You can then have the dumb terminal transfer the file for you and you dont have to write any host code.

Next learn to program the flash, ideally dont erase the space you are running in. Erase one of the other blocks, write it with something and read that back to see that you wrote it. I used to do printfs and deal with a library to make that work, bad idea. I have a very small 10 lines, maybe 15 that prints hex numbers out the uart and for over a decade is sufficient for debugging and "seeing" these kinds of things. Note I do bare metal and bootloaders and whatever is needed for a living at work and for fun at home. Dealing with the flash from a program on this device is not difficult, the flash memory chapter covers the high level flow and it is again not difficult. You always have the boot0 pin and the st bootloader to fall back on if you screw up (unless of course you let smoke out of the chip).

Now you have to decide what you want your bootloader to do, is it always going to be there, etc. Do you want to use a strap pin just like the st folks do? On chips unlike this one you want to definitely use your own strap before messing with things that will brick the chip like when you learn how to program the clocks/pll. I have bricked a number of boards being too overconfident forgetting I didnt have a fallback like the bootloader on this one and game over chip bricked, buy a new one. Anyway common things are wait a couple seconds for a keystroke otherwise boot the application. Or use a strap if set one way boot the application, set the other go into the bootloader and wait for commands. The latter boots the app much faster, the former doesnt require moving any jumpers or holding buttons down, etc.

Next where do you want to keep the bootloader? You have to have the vector table in the right place for the processor to boot but that doesnt mean your bootloader has to be immediately after. this part family has up to 256Kbytes of flash. You could for example have your bootloader near the lower end of that near 0x08000000 and if your design is to have applications and keep the bootloader on the chip then you need to design the applications to live at a different address deeper in the flash. Probably the best solution for a flash based bootloader. if you were say on a raspberry pi, which from our perspective our programs are loaded into ram for us. you might want a branch to the bootloader deep in memory leaving the lower address space for the applications under test, so that when you decide the application under test is ready you dont have to change the linker script when you commit that to the sd card. But this chip is not like that, you want your bootloader first and your applications if you choose to have both bootloader and application on flash at the same time to be deeper in the flash.

With a part like this that has a strapped bootloader which is easy to interface, even if you could erase it, as a beginner at this you dont want to, you want that bootloader as your fallback when you screw up which you will. I dont think you can erase it, at least ST states that it is reserved for them whatever that means:

System memory: used to boot the device in System memory boot mode. The area is reserved for use by STMicroelectronics and contains the boot loader which is used to reprogram the Flash memory through the selected communication interface. It is programmed by ST when the device is manufactured, and protected against spurious write/erase operations. For further details, please refer to AN2606.

You can absolutely use one of the ST libraries if you dont want to understand how things work. I recommend trying both, I find not using the libraries significantly easier, but some folks find the libraries easier, it is up to you to decide. At the end of the day you have to own your program and maintain it, so you either own your code or a combination of your code and all of theirs, it is your responsibility. These chips are easy to program once you get a few minutes/hours experience with each component (again sometimes with the libraries takes a long time sometimes without takes a long time). Basically try both paths, or with st there might be more than one library path. certainly this cmsis stuff is trying to make life easier (by making life overall harder or slower or whatever). Even when you pick a path, every so often, try the other to see if the experience has changed. The vendors basically have to keep changing the libraries, every so often a complete do over, so dont expect long term support for a set of apis you have learned, this is not windows nor linux nor mac. Many reasons why they do this so you should try the new way when it comes as well as talking to the peripherals directly. Remember the boss wont care who wrote the code you are responsible for when it fails or the production has to stop or recalls happen. You own that code and are responsible for it even if you didnt write it, so examine whatever code you borrow and decide how much of it you want to be responsible for. It might save you a day or a week or a month of development time but cost you your job a year later, was it worth not digging in and looking at it?

Can I make a custom Bootloader for stm32f051

3 Answers