USB Virtual COM Port on STM32C071

[gary239955]

I want to use the example project Ux_Device_CDC_ACM.ioc as the basis of a project to create a Virtual COM Port to bridge USB to UART. I made sure I downloaded the patch version stm32cubec0-v1-4-1. I opened the project in CubeMX. I corrected the USBX Platform Settings to USB, then went straight to generate code for IAR EWarm, as I usually do. Again, as usual, I began by trying to compile the generated project, which has always worked for me before. But I get Ux_Device_CDC_ACM - Ux_Device_CDC_ACM        build_ide.ninja:118: multiple rules generate C:/Users/garyd/Downloads/stm32cubec0-v1-4-1/STM32Cube_FW_C0_V1.4.0/Projects/NUCLEO-C071RB/Applications/USBX/Ux_Device_CDC_ACM/EWARM/Ux_Device_CDC_ACM/Obj/STM32C0xx_HAL_Driver_13552679092417003011.dir/stm32c0xx_hal.o        Any ideas?

 

[Florian LR]

Hi ​@gary239955,

One thing I noticed is that although you're using the STM32CubeC0 v1.4.1 patch release, the error path still references STM32Cube_FW_C0_V1.4.0, which may indicate a mix of package versions or an issue in the generated project files.

The error itself (multiple rules generate ... stm32c0xx_hal.o) suggests that the Ninja build system is trying to generate the same HAL object file twice, typically because the source file has been added to the build more than once during code generation.

If you check the file build_ide.ninja around line 118, do you see stm32c0xx_hal.c (or stm32c0xx_hal.o) appears more than once?

Best regards,

Florian LR

[gary239955]

I deleted both directories and started again. I had to close ninja.exe in Task Manager to do that. I unzipped the patch version 14.1 and went through the same process with CubeMX and IAR. I got the same error on compilation. I looked at the file build.ninja (couldn’t find build_ide.ninja), but couldn’t find the references you mention around line 118. Anyway, I’ve zipped and attached build.ninja. Thanks for responding so quickly, by the way.

[Florian LR]

hi ​@gary239955, 

I tried to do the same thing on my side, using same cube FW package version and examples, and reproduced the issue.
While checking the project after regeneration, it seems that all of my HALs files are duplicated somehow, but only after regeneration of the project (I didn’t change the path in CubeMX, I only edited the USBx parameters and regenerate the project). 
So it seems that CubeMX is adding back the HAL files to the already existing project, causing to have the ninja error which is normal because we’re trying to build here multiple times the same file.

I tried to delete the duplicated files and I don’t have the issue (by that I mean I have the issue on the next HAL file but seems normal because it’s also duplicated). But I think we have here what causes the issue. 

Also, about build_ide.ninja file, I think it’s deleted after the fail by EWARM since it’s only used for the build, that’s why you could not find it, sorry for that.

I’ll try to see why we have that issue on CubeMX generation, but I think we have at least a way for you to be able to move forward by deleting these files (keeping the ones that you need).

I hope that will help you and also fix the compiling issue on your side. 

Best Regards, 
Florian LR

[Florian LR]

​@gary239955, 

A few new information about this behavior, opening a fresh project (unmodified by CubeMX), the HAL libraries seems to be added in the project, but they are not pointing to anything, and in the STM32CubeC0 v1.4.1 version I downloaded there is indeed no HAL libraries in the Drivers folder.
Is it possible that you may be in the same case and that you don’t have the content of the HAL drivers ? That could explain why CubeMX is adding these files in the project, since they are not in the FW package, leading to the issue we had with the ninja. 

Best Regards, 
Florian LR