CUBEMX 6.15 with Keil Full Assert bug

[regjoe]

Same problem here (Cube 6.15.0, Keil uVision 

Although HAL is selected,

Cube installed both HAL and LL files for ADC and some other peripherals by mistake. 

which results in a compile error

../Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_ll_adc.c(25): error: 'stm32_assert.h' file not found

---

To get rid of this, I excluded the unnecessary file in the project as shown above and the error is gone.

Edit: Moved from CUBE MX with Keil 5.39 Full Assert bug in stm32l0xx DFP

[Mahmoud Ben Romdhane]

Hello @regjoe ,

Let me thank you for posting.

For more investigation, I suggest please that you provide your Ioc.File.

Thanks.

Mahmoud

[regjoe]

I've attached the .ioc and generated files by Cube.

Thanks

[Pavel A.]

Why USE_FULL_LL_DRIVER is defined if LL drivers are not wanted in the project?

[Mahmoud Ben Romdhane]

Hello @regjoe ,

I reproduced your behavior, and I did not get compilation errors.

The stm32f4xx_ll_adc.c is generated and not used.

Thanks.

Mahmoud

[regjoe]

Hi @Mahmoud Ben Romdhane 

---

@Mahmoud Ben Romdhane wrote:

Hello @regjoe ,

I reproduced your behavior, and I did not get compilation errors.

The stm32f4xx_ll_adc.c is generated and not used.

---

This is strange. If you compile the uploaded project files, you should get at least the following error

../Middlewares/Third_Party/FreeRTOS/Source/include/FreeRTOS.h(71): error:  #5: cannot open source input file "reent.h": No such file or directory
  	#include <reent.h>

Nevertheless, the file stm32f4xx_ll_adc.c is generated, added to the project and compiled.

I've checked that with an #error directive:

../Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_ll_adc.c(18): error:  #35: #error directive: 
  	#error

For me, the generation of an LL file, althought HAL is selected, is confusing me.

I do not see any reason for that. Is this a bug?

But I agree, the error only appears only in my project, because as @Pavel A. mentioned, the problem is that in my project USE_FULL_LL_DRIVER (plus USE_FULL_HAL_DRIVER) is defined.

The reason is that I started the project in CubeIDE and mixed HAL and LL driver files. For one or another reason I tried to skip LL HAL and driver files but for FMC usage, it seems to me there is no HAL replacement.

Therefore I kept both defines in my project settings. Is this wrong?

BTW:

I tried to generate the CubeIDE project file. For that I removed the "generate under root" tick.

When I tried to import the project into CubeIDE, there were no files linked to the project, the project was empty.

To my surprise, the directory looks like this

I opened the .project file in this directory and the content is 

<?xml version="1.0" encoding="UTF-8"?>
<projectDescription>
	<name>hiplex8400</name>
	<comment></comment>
	<projects>
	</projects>
	<buildSpec>
	</buildSpec>
	<natures>
	</natures>
</projectDescription>

I opened the .ioc file and it contains the following line:

ProjectManager.ToolChainLocation=hiplex8400\\hiplex8400

I removed the path after "=", reopened the file in CubeMx and re-generated the project.

Now the project file is, as expected, located in "STM32CubeIDE" under root and the project contains source files.

Is this an already known bug?
 

[Pavel A.]

> For one or another reason I tried to skip LL HAL and driver files but for FMC usage, it seems to me there is no HAL replacement. Therefore I kept both defines in my project settings. Is this wrong?

The symbol USE_FULL_LL_DRIVER enables inclusion of .c source files of LL drivers. The LL drivers are mostly inline (headers-only) but some of them have large functions in .c files. USE_FULL_LL_DRIVER is a safeguard when LL source files should not be used, but are included in build by the generator or whatever reason. Of course you can tidy up the project by removing unused items.

[regjoe]

I removed USE_FULL_LL_DRIVER and LL source and header files from the project, except for FMC, for which I found no HAL replacement. This works on my side, thanks for the hint.

The question remaining is why stm32f4xx_ll_adc.c is generated and added to the project by CubeMx.

[Mahmoud Ben Romdhane]

Hello @regjoe ,

While enabling ADC with HAL, stm32f4xx_ll_adc.c should not be generated.

The issue is confirmed, and an internal Ticket was submitted to the Development Team:

(Internal Ticket Number: 218904).

I will keep you up to date when the problem is solved.

Best Regards.

Mahmoud