I use MDK-ARM v5.24.2, CMSIS V5.0.1, MDK-MIDDLEWARE V7.4.1, STM32F4xx_DFP V2.11.0, new a project use the STM32CubeMX of the STM32Cube Framework(API), add a usb host msc to read and write file in the u disk. But I find that: 1. the "Keil::CMSIS Driver:USB Host:Full-speed" require CMSIS:RTOS, but there are two choices: "ARM::CMSIS:ROTS:Keil RTX" and "ARM::CMSIS:ROTS:Keil RTX5", there seems that I can only chose "ARM::CMSIS:ROTS:Keil RTX5" because I have add the "CMSIS::RTOS2(API):keil RTX5". 2. If neither chose ""ARM::CMSIS:ROTS:Keil RTX" nor "ARM::CMSIS:ROTS:Keil RTX5", there is a error after compile: C:\Keil_v5\ARM\PACK\Keil\STM32F4xx_DFP\2.11.0\CMSIS\Driver\USBH_FS_STM32F4xx.c(166): error: #5: cannot open source input file "cmsis_os.h": No such file or directory 3. If chose the "ARM::CMSIS:ROTS:Keil RTX5", there is a error after compile: C:\Keil_v5\ARM\PACK\Keil\MDK-Middleware\7.4.1\FileSystem\Include\fs_os.h(272): error: #81: more than one storage class may not be specified How to fix this? Thanks!
If you still use the oldest version of the CMSIS-RTOS or RTX, this is may be fine for you. But I want to use the newest CMSIS and MIDDLEWARE with the STM32CubeMX framework. By the way, the document below is released in 2015, today is 2017 now! http://www.keil.com/pack/doc/STM32Cube/General/html/cubemx.html Someone should update the document and fit the CMSIS-RTOS V2 and the new middleware.
I don't think the middleware has caught up with the new RTOS. Even if you select RTX5 it still asks you to use the original RTOS API, but will still throw that error. You will need to log a support case to bring up the issues with Keil and ARM directly.
The middleware is lib file and is RTOS agnostic. ARM should update the device driver which uses the CMSIS-RTOS V1 only.
Hi, We are facing this same error. Was there a support case opened with Keil/ARM and a resolution?
Thanks.
Was there a support case opened with Keil/ARM and a resolution?
I can't speak for the original author but I raised a case with both Keil and ST about updating the STM32F1 drivers and adding drivers for the F0(+) and F3. The response wasn't great.
First of all they both pointed to the other as the one to raise the case with. ST just stopped responding when I pointed out that it is the manufacturer that provide the drivers. Keil were a little better. They said that the request has gone to the "Product Manager", although they finished by saying "Please register for ... newsletters and when the update regarding these drivers is available, it will be published.". They have left the case as "Awaiting Fix".
I'd recommend that anyone wanting the drivers added / updated raise a case with both ST and Keil. Remind ST that they are the providers of the drivers if they try to push you to Keil. If enough people raise cases they will see a market for providing the drivers.
Similarly if you want the middleware updated to use the latest compiler and RTOS raise a case with Keil.