STM32CubeMX generates HAL library code that does not compile

[Jwork.1]

Hello,

Under linux (project generated by STM32CubeMX), the compiler reports illegal implicit casts from void * to PCD_HandleTypeDef in the HAL libraries.

The problems are in two files: usbd_conf.c and usbd_cdc.c

I solved this by following the example in other HAL sources, by adding explicit type casts for all reported problems like so (line 354 of usbd_conf.c):

 hal_status = HAL_PCD_DeInit((PCD_HandleTypeDef*) pdev->pData);

The errors are present in the latest version of the HAL (I updated STM32CubeMX and the project today)

While correcting this I wondered about two things:

1. Why do only these specific files not include the type casts that are included in other HAL library files.

  Done by a different programmer / added later to the HAL?

2. Why were these errors not caught by ST?

  Perhaps this was not tested under linux or not tested from a freshly generated project?

Or perhaps I am doing something wrong here?

Thanks for your reply and best regards,

John

Example error message:

arm-none-eabi-g++ -c -mcpu=cortex-m3 -mthumb  -DUSE_HAL_DRIVER -DSTM32F103xB -IInc -IDrivers/STM32F1xx_HAL_Driver/Inc -IDrivers/STM32F1xx_HAL_Driver/Inc/Legacy -IMiddlewares/ST/STM32_USB_Device_Library/Core/Inc -IMiddlewares/ST/STM32_USB_Device_Library/Class/CDC/Inc -IDrivers/CMSIS/Device/ST/STM32F1xx/Include -IDrivers/CMSIS/Include -O3 -Wall -fdata-sections -ffunction-sections -g -gdwarf-2 -MMD -MP -MF"build/usbd_conf.d" -x c++ -Wa,-a,-ad,-alms=build/usbd_conf.lst Src/usbd_conf.c -o build/usbd_conf.o

Src/usbd_conf.c: In function 'USBD_StatusTypeDef USBD_LL_DeInit(USBD_HandleTypeDef*)':

Src/usbd_conf.c:354:37: error: invalid conversion from 'void*' to 'PCD_HandleTypeDef*' [-fpermissive]

  hal_status = HAL_PCD_DeInit(pdev->pData);

[Pavel A.]

This message is because you compile C code with C++ compiler.

Conversion from void * to any pointer is valid C.

But g++ errors it, even despite of -fpermissive

So, either use the proper compilation mode (C, not C++) or find a way to downgrade this error to warning.

Maybe , update the g++ compiler if available.

Again, this is perfectly valid C, please don't force C++ rules onto legacy C code,

-- pa

[Jwork.1]

Thanks Pavel! Sorry for not providing the gcc/g++ info in my post, let me explain that.

I want to port a C++ USB library to create a MIDI audio device, hence the need for C++.

What is the recommended way of doing a C++ project based on HAL? I wonder how other people do this.

I did not see an option for it in the STM32CubeMX project generator. So this is how I proceeded:

To be able to use C++, I first started by keeping track of which files are pure C, which are C++, rename main.c with main.c++, compile that with g++, link everything with g++, use extern"C" statements in my C++ code etc.. This becomes complicated and I could not get this to work quickly. See (*)

Therefore I then simply switched the compiler to g++. Everything I needed from HAL has apparently been prepared for this, except the two files I mentioned still contain those c-only implicit type casts.

Using this approach I need to change out two files from the usb subsystem and it works, so that still seems the easiest way for me if I regenerate the project from STM32CubeMX in the future.

I still feel it would be handy if ST added the type casts giving me the option of creating a C++ project by switching compiler, keeping intact the make and file structure as generated by STM32CubeMX. But perhaps there is a better way?

Thanks again,

John

(*) https://isocpp.org/wiki/faq/mixing-c-and-cpp#overview-mixing-langs

[JoniS]

You can tell gcc compiler to compile X file with c compiler instead of C++.

[Jwork.1]

On 2020-02-04 09:59, ST Community wrote:
Yes I understand. That would still leave me with a mixture of C and C++
files. I will stick with my own solution :)