Stm32 Cmsis Tutorial
Mauricette Atencio
I'm want to start projects using CMSIS on STM32. Surfing the net, I couldn't find any specific tutorial. Some starts project using SPL (which is discontinued by ST). I want a source to learn CMSIS on stm32cube.
hi everyone. I'm want to start projects using CMSIS on STM32. Surfing the net, I couldn't find any specific tutorial. Some starts project using SPL (which is discontinued by ST). I want a source to learn CMSIS on stm32cube.
If you want to start with register-level programming, perhaps using symbols defined in the CMSIS-mandated headers as TDK outlined above, well, ST does not encourage nor support it, stubbornly promoting Cube in all its forms.
But there's nothing special to it - simply get a Nucleo or one of the simpler Disco board, read its manual, read the datasheet and first few chapters of RM of your STM32 model, and start with simple loopdelay blinky.
Thanks to the feedbacks I have received, I reached to the conclusion that it's really hard to cover a topic like this one in the room of a blog post. So, I started writing a book about the STM32 platform. In the free book sample you can find the whole complete procedure better explained. You can download it from here.[/box]
If you landed to this page, you probably already know that I've covered this topic in the past. I showed in a series made of three posts how to successfully setup a complete Eclipse/GCC ARM tool-chain to develop applications for the STM32Nucleo-F4 developing board. Since then, many people have reported me positive feedback on that tutorial. But, some of them had serious troubles in getting those instructions working for other STM32 families (F0, F1 and so on). This was mainly caused by the GNU ARM Eclipse plug-in, or rather by the included templates in the plug-in. When a new project is created using the plug-in wizard, a template is used depending on processor family. Unfortunately, the plug-in author has updated just the template for STM32-F4 family to the more recently STM32Cube-F4 HAL framework from ST (which still supports only commercial IDE.....), leaving the other templates still based on the old Standard Peripheral Library, which is no longer supported by ST and STM32CubeMX tool used in my tutorial. This causes my instructions to be wrong for processor families different from STM32-F4.
In this post I'll show you how to setup from scratch an Eclipse project to develop applications for STM32 platform using the latest version of STM32Cube-Fx framework (the latest version available at time of writing is 1.6 for F4). Unfortunately, at the moment I can test these instructions only on a STM32-F4 processor, but I'm going to buy other Nucleo boards to do tests. In this article I won't explain again all the steps required to install Eclipse and GCC on your computer. If you still haven't installed the base tool-chain, you can start reading from this post and stop to the paragraph named "Create a test project". When ready, you can come back here again and continue the reading.
This is a really common question: which tool-chain is the best one to develop apps for STM32? The question is unfortunately not simple to answer. Probably the best answer is that it depends on the application. First of all, the audience should be divided between professionals and hobbyists. Company ofter prefers to use commercial IDEs with annual fees that allow to receive technical support. You have to figure out that in business time means money and, sometimes, commercial IDE can reduce the learning curve (especially if we consider that ST gives explicit support to these environments). However, I think that even companies (especially if they are small organizations) can take great advantages in using an open source tool-chain.
In the next step you have to configure your processor. For a STM32-F4 you have to choose Cortex-M4 core, while for a STM32-F1 you have to choose Cortex-M3. The Clock, Flash size and RAM parameters depends on your Nucleo MCU. For Nucleo-F401RE you can use the same values shown in the following picture. Set the other options as shown below.In the next step leave all parameters unchanged except for the last one: Vendor CMSIS name. Change it from DEVICE to stm32f4xx if you have a STM32F4 based board, or stm32f1xx for F1 boards, and so on.Click on Next. You can leave the default parameters in the next steps. The final step is about the GCC tool-chain. You can use these values:
Ok. Now the hard part starts. The project generated by GNU ARM Plug-in for Eclipse is a skeleton containing Cortex Microcontroller Software Interface Standard (CMSIS) by ARM. CMSIS is a vendor-independent hardware abstraction layer for the Cortex-M processor series. It enables consistent and simple software interfaces to the processor for interface peripherals, real-time operating systems, and middleware. It's intended to simplify software re-use and reducing the learning. However, the CMSIS package is not sufficient to start programming with a STM32 chip. It's also required a vendor specific Hardware Abstraction Layer (HAL). This is what ST provides with its STM32Cube framework.
The above diagram try to explain better all the components involved in the final firmware generation. CMSIS is the universal set of features developed by ARM, and it's common to all Cortex-M vendors (ST, ATMEL, etc). ST HAL is the hardware abstraction layer developed by ST for its specific devices, and it's related to the STM32 family (F0, F1, etc). The Device HAL is a sort of "connector" that allows the two subsystem to talk each other. It's a really simplified view, but this is sufficient to start programming with this architecture.
The files I've highlighted in blue in the above picture are generated automatically by the GNU ARM Eclipse plug-in. They are what it's called the Device HAL part in the previous diagram. These files are substantially empty, and should be replaced by custom code, both specific for the single vendor (ST in our case), both specific for the given MCU (STM32F401RE if you have a Nucleo like the mine). We are going to delete them.
Second, we need to configure how the application is mapped in the MCU memory. This work is accomplished by the link-editor (ld), which uses the three .ld files inside the /ldscripts Eclipse folder. The file we are interested in is mem.ld, and we need to change the FLASH origin address from 0x00000000 to 0x08000000, as shown below:
Where does this number come from? It's not a magic number. It's simply the address where the internal MCU flash is mapped in all STM32 microcontrollers, as you can see in the picture below extracted from the MCU datasheet.
I'm aware of the fact that the whole procedure is not straightforward, but I can guarantee you that it becomes clear after the first time. I did all the best to describe the whole process in a clean and simple way, but comments and suggests are welcome.
But now I'm working on a Inemo M1 Discovery board based on a STM32F401REY6 MCU and I tried to apply this tutorial without success. When I try to write my .hex file thanks to my st-link v2 and st-link utility I got:
_ i choose a STM32F103RB-Nucleo project to copy the system_stm32f1xx
> i don't know if it's related, but one of my thought is about vector table localisation, in my datasheet i see "the vector table of the customer's application must be present at the start address of the main flash"
It seems that I can't choose the start address in my .hex file while "Programing" with St-Link Utility ( Start Adress is set to 0x00000000) so I try to write in a protected area... I tried to manage it with the St-Link Utility command line interface BUT the dress choice is only available for.bin file. Is it possible to manage the writing area in Eclipse ( mem.ld seem not to have an influence on the Start Adress)
Unfortunately, without having the board in my hands is really difficult to address the issue. Try to check if all global defines are correct (especially the one defined in the eclipse project settings). I'm wondering if you never was able to flash this board or if you can flash it using some other images (maybe supplied by ST). However, try to ask on the ST forum.
I have the same board as you have in your tutorial, a Nucleo-F401RE and followed your instructions exactly. But I'm getting the same error as Louis. The problem hex file has its initial address at 0x00000000, whereas the hex file generated by your original tutorial, which programs and verifies correctly has its origin at 0x080000. So there must be a problem with the loader settings somewhere? Maybe you can let us know what changes have to be made to get the FLASH origin set correctly.
Thanks again!
Hi Alex,
When gcc compiles a source file, it generates a file that has ".o" extension. Those files are called "relocatable", because the instructions inside them are not bind to physical addresses, but are relative to the origin of the file (they all starts from 0x0000). It's a link editor task to generate an absolute binary that will start from the real physical address. So, the start address is decided inside the mem.ld file in your project:
Hi Carmine,
Yes, that was it. Somehow the FLASH origin was set to 0x00000000 in mem.ld. The RAM size was set to 96K which I reduced to 64K. The project now loads and runs perfectly on the STM32F401RE Nucleo. My next two steps are to attempt the same on an STM32F303 Nucleo. Then, to attempt to use the STM32CubeMX GUI application to generate the initialization code for all the peripherals I want to use.
Thanks again!
Once again, thank you for this tutorial! It has helped me a lot and this made me blink the lights on my STM32VL-Discovery after giving up hope following other tutorials. One thing I noticed, though, is that Eclipse spews out a bunch of error messages about symbols not being resolved but what's weird is that the project compiles alright and even works when I uploaded the hex file that was generated. What could be the problem here?
93ddb68554