How to Create a Super Simple Bootloader, Part 2: Linker File Hands On

Learn how to create your STM32-based application using STM32CubeIDE and use its Linker Script to create segments of memories, place variables in RAM and FLASH, allocate functions in the desired memory region, and even how to share code between your application and custom bootloader.

The STM32CubeIDE is be used to create a super simple bootloader, after covering the basics of the linker script and evolves into creating an application that runs after the bootloader starts in a different portion of the memory. This video series also shows how to debug Bootloader and Application simultaneously and how to create a static library shared between both projects.

Benefits you will take away:

• Understand the basics of the linker script
• Understand how to place variables in RAM and FLASH
• Understand how to create functions in RAM and FLASH
• Learn how to create a super simple bootloader
• Learn how to offset the interrupt vector and create an application to run in a different memory region
• Learn how to debug bootloader and application
• Learn how to share an API between bootloader and application


In this video: we’ll cover how to create and place a function in a specific memory region and how to create such region in the linker script. This also covers what is a function pointer and how to use it.

Hardware requirements: NUCLEO-G071RB is preferred, but any STM32 with Cortex-M0+ or higher can be used for the hands-on session with some minor changes. Note: STM32 with Cortex-M0 needs a different strategy when it comes to video 3 and onward, as the M0 core does not allow changing the NVIC address position due to lack of the VTOR register.

[martinlintzgy]

Brilliant. This series is helping me a lot.
In the cube documentation, I would have no idea where to start looking for this information!

[nedbazzvictoria]

Yet another GREAT "down n dirty" video into the silicon so exposing the great underlying combinations of hardware ans software designs by ST expertise; riveting stuff and invokes the note taking and saving to watch again and again. I really wish ST would give the names of the presenters, at least so that we could form some form of personal 'knowledge' of the fantastic presenters. Such knowledge would inspire directed questions for ST people "known to be Aces" which would allow the use of assumed common ground upon which to base specific technical questions in the language and expressions used by the presenters.
Just a thought!
Thanks again guys.
Cheers, n.

[JayDee-bu]

What is this 'LED_GREEN_GPIO_Port' from the last video you speak of? It was not mentioned in Part 1.

[danielwarzecha]

Thank you, excellent material coverage and explanation

[poria]

Hi, thank you for the great video tutorial. I'm trying this on stm32f407 and things are not the same.

For start, there are two linker files. RAM and FLASH.
I went ahead and used the FLASH linker.

Then, Ram and Flash sizes were different, I set the MY_MEMORY block to 0x80f8000 (992KB from the beginning of flash) and LENGHT to 32K as shown in the video.

Then there is a problem with the Blink function. Its not showing up in the MY_MEMORY block in memory region.

I went ahead and set up .RamFunc and once again things are not the same. The function resides in FLASH->.RamFunc and the Run address is the same as the Load address both in the range (in flash).

Is this not meant for the f series? Should I quit or is it something I'm doing wrong?

[julienc.]

Hello,
Is there a tutorial regarding the specific compiler languages?
Thanks

[MCU_STM]

You have referred to an unknown reference many times during video. You many times mentioned that you did some part of code in the last video that it really is not exist inside the part1 video.

[swathigp]

Great content !!!But the background music is very distracting!

[Kefford]

Hi, first of all thanks for making these videos as this is a complicated topic and we need all the help we can get!

I am a little confused though. I have followed and understood that we can modify the linker file, create our own regions in flash and ram and that we can store our own variables/functions in the regions.
What is the bigger objective here though, it hasn't been explained why we would need to do any of this for a bootloader?

Is this just so that a bootloader and an application can co-exist in a single CubeIDE project? If we want to make a single bootloader that can be used in multiple projects, wouldn't it be better to have two separate CubeIDE projects?

My understanding of bootloaders is that they are traditionally programmed from page/sector 0 in the flash and the application is offset by for example 32Kb so the app begins at flash + 0x8000. Is there a reason why in this video you chose to put the MY_MEMORY region at the last 32Kb instead?

[roshanahire]

First of all thanks to making this video for us,
I understood whole video. and how it is working ...
But got a question, if we can write a function in FASH section and can access it by function pointer from another program too (function in BOOT app can be access from MAIN APPLICATION software using function pointer).

then why we need to write a function in ram function (in .dada), and as you mentioned that it will be stored in FASH only but copied to RAM again.

what that means, does it means that function will be store at two places one in flash and another in .data section too???

and what is its actual benefit

[sureshkrishna]

Can someone explain why at times in the video in Linker script the Flash is defined as 96K and 32K ??? I'm so confused

[nklyerd]

sir..error [44] ocuure during the compaile time, what is the reason