HAL Libraries - Importing and Using

Rod,

I've been using CubeMX + Atollic Studio to program a STM32F103. I'm using the STM32 HAL, and it seems to be working fine for me.

First setup CubeMX by downloading the MCU Package:

Create a new CubeMX project, and enable the peripherals you want (let's go with the GPIO & UART):

Go to the 'Configuration' tab and configure the settings:

This is how my project settings look:

Note that you can select between the 'LL' & 'HAL'. The HAL is easier to work with due to the higher level of abstraction:

Now click on 'Generate' source code. It should automatically create/update the Atollic TrueStudio Project, add the initialization code (so that you don't need to manually configure the baud rate, and set the GPIOs to the alternate function i.e. UART) & import the required drivers.

Launch TrueStudio, and you will see something like this:

If you open up the those functions, you'll see that CubeMX has already implemented the code required to setup the peripheral.

To transmit you can try adding this after the peripheral initialization:

  char mword [] = "Boot!\n";
  HAL_UART_Transmit(&huart1, &mword, sizeof(mword), 300);

To toggle the GPIO, try:

HAL_GPIO_TogglePin(GPIOC,GPIO_PIN_13);
HAL_Delay(1000);

Have a look at the documentation for the HAL & LL drivers if you want a list of all the driver functions, how to use them or what they do. For the STM32F1, I use this:

Regarding the preprocessor macros/symbols,

TrueStudio > Project > Build Settings > C/C++ Build > Settings > Tool Settings > Symbols (under C Compiler)

I wouldn't bother with copying files over manually - CubeMX does all of that for you!

Create a CubeMX project, and add you code between the /*User Code*/ comments. When you want to modify pinmuxing, enable peripherals, or even change peripheral configuration, open CubeMX, make your changes and regenerate the project. CubeMX will not modify anything within the /*User Code*/ braces.

It's probably easier to start with the CubeMx project, and import whatever code you have rather than the other way around.

Hi Avner,

I wanted to click 'helpful' twice to reflect the amount of great detail you've given me - so thank you.

CubeMX will not modify anything within the /*User Code*/ braces.

I wondered how that bit worked following on from koudelad comments, so will remember that as I start to work my own projects from scratch.

I have managed to do a CubeMX project from scratch, albeit just generating some basic code. The problem I have is that I already have the example from the STM32 board's Cube package, it does 99% of what I want, and now I wish to modify it slightly.

Rod

This is what my project looks like:

CubeMX generated the hal_conf.h file, and automatically defined the macros.

Since you're working with an example project, you could try importing the drivers manually.

The hal_conf.h file also contains a bunch of other defines, and does a:

#ifdef HAL_UART_MODULE_ENABLED
 #include "stm32f1xx_hal_uart.h"
#endif /* HAL_UART_MODULE_ENABLED */

Try generating a new CubeMX project, and look at how the whole thing is structured. I think that you should be able to copy over files from the CubeMX project to your example, and with a little fixing, it should work.

Good advice, thank you again Avner.

The more I browse around and try stuff the better I'm getting. I have been in the ...hal_conf.h file and enabled the UART (as in photo below) although that definition never seemed to get recognised in the HAL_UART.c and so I changed the #ifdef to #ifndef to get the code to be included....probably a bad approach as there is something obviously not quite right still. I suspect my includes or where the IDE is looking is incorrect although strangely I can trace through from one declaration to the next (so the IDE knows where everything is even if the compiler doesn't).

I'll likely be giving this a break for now as I think my brain is getting confused - a nice fresh start again tomorrow might help along with all these great comments. A screenshot from my IDE looks like this:

I have two projects open - the SensorTile example and my own, very basic, UART5.

Rod

Hi, is your basic UART example working? As a starting point try something simple, like sending back every received character. Verify with PuTTY or some other terminal program that it works.

Hi kulky64, Good point, I compiled the code for reference reading but never actually tried building it or debugging on the SensorTile board. I made a new version in CubeMX (which is a really great tool) and activated both the UART5 and LP_UART. I added some code to output a few bytes on UART5 and LP_UART. I'm seeing bytes on my simple oscilloscope directly from pin 6 of the SensorTile and on CN9-pin2 (having made the SB changes you helpfully suggested). However I wasn't convinced it was actually my bytes (I used the 'U' as it is 0x55 and easy to spot). Commenting out those lines and I could still see data on the CN9-pin2 , which is strange. I'm carrying on looking around. Although I also initialise LP_UART and send bytes to that I cannot see anything on the correct pins of the SensorTile (pins 12 and 13 which are F8 and F9 of the STM32L476JG device). Of course, there is every possibility I have damaged those pins with my clumsy eyesight and shorting pins whilst testing! The data on UART5 also appears whilst single stepping in debug mode, which backs my theory up.

Anyway, the investigation continues, and although I am now a long way from the actual Sixth Sense Design Challenge I feel I am really learning a lot. I even almost successfully imported the BSP for the SensorTile into my project which didn't seem to be an option from CubeMX (I say almost because it fell over compiling).

Apart from these issues I've found it enjoyable looking around the CubeMX to see what can get added, selecting the pins, comparing to the datasheets, testing the pins etc. Thanks for all the help and I'll post when I get another breakthrough (the first breakthrough being my simple code actually compiled and downloaded today).

Rod

14rhb  wrote:

 

... I added some code to output a few bytes on UART5 and LP_UART. I'm seeing bytes on my simple oscilloscope directly from pin 6 of the SensorTile and on CN9-pin2 ...

Whoa. Why do you expecting to see anything on pin 6 of the SensorTile and CN9 pin 2? If you trasmit something from UART5 on SensorTile you should see it on pin 7 of the SensorTile and pin 1 of CN9. So the flow of the signal is like this:

STM32L476JG (PC12, ball B3, UART5_TX) -> SensorTile (pin 7, signal TXD-USB_DM) -> solder bridge SB20 -> level converter ST2378ETTR -> CN9 pin 1 (signal now named UART_RX because this is from MCU on Nucleo point of view).

When you are dealing with RXD and TXD nomenclature you should pay attention from standpoint of which device this is taken. Also just to verify: you have not connected any USB cable to USB connector on the Cradle Expansion Board and jumper on J2 header is placed between 1 and 2 (VIN from Nucleo 5V Output). Right?

I've got 100%  UART data now on CN9-pin1, thank you so much kulky64 for all your time taking me through this.

Point-by-point:

• I was looking at CN9-pin2 for the very reason you mention, that is was detailed as the UART_TX but now I see what you mean about being careful. There was nothing on the CN9-pin 1 at this time.
• The USB was still connected to my PC and the J2 jumper was incorrectly set to USB.
• I changed CubeMX back to provide UART5 as asynchronous rather than half-duplex which I changed whilst trying to mend it earlier.
• A few attempts at building, stopping the existing debug etc (just me getting used to the process still) and wow - the oscilloscope trace went wild...zooming in I can easily see my bytes due to the '0101' nature of the 'U' character.

Thanks again for all the time you have spent helping me here. What a great way to finish off Sunday

Rod

I've got 100%  UART data now on CN9-pin1, thank you so much kulky64 for all your time taking me through this.

Point-by-point:

• I was looking at CN9-pin2 for the very reason you mention, that is was detailed as the UART_TX but now I see what you mean about being careful. There was nothing on the CN9-pin 1 at this time.
• The USB was still connected to my PC and the J2 jumper was incorrectly set to USB.
• I changed CubeMX back to provide UART5 as asynchronous rather than half-duplex which I changed whilst trying to mend it earlier.
• A few attempts at building, stopping the existing debug etc (just me getting used to the process still) and wow - the oscilloscope trace went wild...zooming in I can easily see my bytes due to the '0101' nature of the 'U' character.

Thanks again for all the time you have spent helping me here. What a great way to finish off Sunday

Rod

Glad it is working. Now you can utilize virtual serial port on ST-LINK and check if you receive characters sent by SensorTile in terminal program on your PC. Connect some female to female jumper cable from ST morpho connector CN10 pin 37 (also connected to CN9 pin 1) to connector CN3 pin RX (provided you already opened SB13). Set baudrate and other parameters in your terminal program to match what you set in firmware on your SensorTile and watch if you receive something in terminal.

Just like before I read what you said and followed it on the schematics to see if it made sense which it does. A bit of trial-and-error with PuTTY and my SensorTile boards would like to say:

Rod

If you want you can try another direction, connect anothwer wire from CN3 pin TX to CN10 pin 35 (maybe you already done that). You have to be careful now and ensure that the MCU on the Nucleo board does not drive the TX line too (because you have now SB63 shorted) -> potential of conflict here. Modify the firmware on the SensorTile so that it sends back every character received or one character higher or something. Type some characters in terminal a watch if they come back. If you are not sure, maybe don't do this exercise.

Thank you. I might try this out after the Sixth Sense Challenge has finished, just in case I damage the board - it would be a shame to do that after getting this far !

Rod