Previous Blog: STM32L4R9I-Discovery Board: Part 3 (the development cycle)


This is my final blog that will form the basis of my roadtest review on STMicroelectronics STM32l4R9I-discovery board. I have managed so far to get the development cycle to work with the toolchains that I chose - I can load and reload the examples in the STM32CubeL4 package as I want and most of them work for me. I modified a few of those as well to make my own 'first application'. This blog details using the STM32CubeMX software to create a project from scratch - my Roadtest application stated that I would build a simple project and I thought this would be a very basic MP3 Music Player.


1.     STM32CubeMX - Creating a Music Player


This software provided by STMicroelectronics is meant to assist the designer in the initial configuration of their board and will generate the appropriate skeleton code and libraries for them depending upon their choices.


For my example I have selected two of the Middleware options: the FATFS using the external SD card and the STemWIN. Many of the options are greyed out but the tooltip is really helpful here and suggests what other peripherals are required to get the option to work.

I am not completely sure at this stage but added the GFXMMU and set my display interface to use it.

Initially the red crosses and yellow exclamations seem to spell out doom. What they are actually showing are the peripherals that cannot be utilised and those that can, but with some changes to other settings. They do however appear first to signify errors and warnings!


Under the project settings I selected a project name "MusicPlayer" and set my toolchain to SW4STM32.

And I got the following warning the first time around:

I clicked NO and changed to the 'Clock Configuration' tab of CubeMX to take a look at what this warning referred to. Actually at that point I also noticed that the clock tab did have a warning cross beside it. The clock diagram did show something in red on the PLLM3 line; I didn't understand that but a very promising popup appeared and I agreed to the automatic resolve...

As if by magic, the software changed other dependant settings, searching for a solution that worked. Eventually values were found that allowed all the clock frequencies required by my design to be generated and these dividing values appeared in the relevant boxes:

A final view tab is the CONFIGURATION tab which looks like this:

There were no errors when I clicked on GENERATE CODE and the following project was created for me. It (obviously) looks quite similar to the examples I have already been using, although it will have the basic Middleware functions there will likely be very little code in the main...that part is for me to craft. I can now click on the CPROJECT file to open this in my SW4STM32 IDE.


2.     SW4STM32 - An Initial Build


Having a look around the project I can see the FATFS and STemWIN folders that will contain the libraries I will use for that functionality. Before doing anything I want to see if this project will compile...

The included examples always compiled to produce a BIN file whereas this seems to have generated a HEX file which I could successfully program into my board (albeit I cannot check it is working as there is nothing to see).


3.     Adding Some 'Screenage'

It would be good to know my program is running so the first thing I will do is add some message on the screen. I'll use the LCD-BSP library for that.


For this I thought I would simply copy and paste some code from the BSP example - which I had ran previously and understood the basics of. The code was something like this and I inserted it into my main:

 /* Graphic application */  

  //Music Player Welcome using BSP
    while(BSP_LCD_IsFrameBufferAvailable() != LCD_OK);
    char desc[50];

    /* Set LCD Foreground Layer  */


    /* Clear the LCD */

    /* Set the LCD Text Color */

    /* Display LCD messages */
    BSP_LCD_DisplayStringAt(0, 50, (uint8_t *)"A Music Player", CENTER_MODE);
    BSP_LCD_DisplayStringAt(0, 75, (uint8_t *)"for Element14", CENTER_MODE);


Unfortunately my understanding of how SW4STM32 pulls in additional folders seems to fail me. The disk folder structure and the SW4STM32 structure are completely different and it does not seem to be a simple matter of copying and pasting the additional BSP driver folder into the project. The net effect was a series of errors as most of the BSP-LCD functions and definitions were not defined.


Back in CubeMX I re-made the project with some different options, hoping that one of them might populate up the DRIVERS/BSP folder. The BSP folder was still blank. Looking online I found this article which seems to describe that the BSP drivers should be linked in afterwards.

Therefore, I remade my project to overwrite any mistakes I had made up until now. Then I tried to follow the comments in the above link. The article, although MEMS biased, summarises to:

Summary: It seems that CubeMX and MEMs BSP can be easly integrated. The general idea is:

-generate CubeMX and enable required resources. In case of MEMs it's I2C1, In case of L476G (Eric's example) it's DFSDM1

-add include search paths to your project

-add *.C files from Drivers folders to satisfy linker

-then work with the API

The first step is done, I just need to add the new search paths. Whilst searching for how to do that I found another good tutorial. Although it was not aimed at my board it detailed how to use the STemWin software from CubeMX. Please see . I thought this would be useful as I could at least make a splash screen to verify the code has at least started. The process did indeed generate some STemWIn code but it failed to compile dur to an error with GRAPHICS filepath missing. More searching around the internet and I found a article regarding issues I can seen previously,… . This current forum post seems to indicate the issues I a having with CubeMX are bugs including the desire to integrate the BSP into my project.


Determined to get this to compile I looked in the project settings to see there is a path for MusicPlayer2/GRAPHICS although no such folder exists in my I added an empty one.

Adding a CLEAN and BUILD-ALL indeed allowed the project to build and a HEX file to be produced (I always check the date/time stamp to ensure it is a current file). Unfortunately I'm not getting the Princess Leia spalshscreen that I wanted (actually what I really wanted was to display the holographic image like R2D2 does but that seems a long way off now).


4.     My Next Steps

At this point perhaps I can see I am getting caught up in the intricacies of the software rather than being able to review the actual board, although the two are closely intertwined. I knew that ARM is a very steep learning curve and perhaps my stubbornness to adopt the open source IDE/toolchain rather than some of the 'more refined' and supported third party toolchains is my downfall. But being open-source I know that my choice will continue to work rather than in a few more weeks being constrained to a certain build size. Therefore I can in time chip away at my ARM learning and hopefully progress. I don't think I am far off cracking this and just need to find the right online tutorial that allows me to understand a few concepts.


I could carry on testing out ideas but I also have some other projects I would like to work on - therefore I think this will be the last blog for now on the STM32L4R9I-discovery board. I will collate all of my thoughts and findings into my final Roadtest report. I can leave this board on my desk and set aside a few hours each week to have another go at exploring the intricacies of it....finally all the bits will start to fall into place. I'm not too disappointed either - I love the board, have cracked the design cycle for my setup and got some great demos to run. Post roadtest report I will endeavour to update E14, OpenStM32 and ST forums on any findings or progress that I make.