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 I "Include path": C:\Keil_v5\ARM\PACK\ARM\CMSIS\5.0.1\CMSIS\RTOS2\RTX\Include1 and neither chose "ARM::CMSIS:ROTS:Keil RTX" nor "ARM::CMSIS:ROTS:Keil RTX5", there is no compile error. But there is a HardFault error when debugging. I use the Host:MSC(USBH_MSC.C/.H) user code template. After "USBH_Initialize(0U)" there is a HardFault error. USB MSC thread: USBH_Initialize()->USBH_Delay()->osDealy() osRtxTimerThread: osMessageQueueGet()->HardFault_Handler() I have add the stack and/or heap of the RTOS, fs and usb component. I also refer to the "Option2: Configuration via STM32CubeMX" in the http://www.keil.com/pack/doc/STM32Cube/General/html/cubemx.html It seems that the Middleware can't compatible with the STM32CubeMX framewark API?
Hi,
you can take a look at prepared project for MCBSTM32F400 board, it can be found in c:\Keil\ARM\PACK\Keil\STM32F4xx_DFP\2.11.0\MDK\Boards\Keil\MCBSTM32F400\Middleware\USB\Host\MassStorage\
Best regards, Milorad
Yes, I have refered to the MassStorage example of MCBSTM32F400, but this example use the RTE_device.h. I what to use the STM32CubeMX framework component to configure the USB low peripheral, clock and other code. There is a lot of different between RTE_device.h and STM32CubeMX framework, please refer to the following document: http://www.keil.com/pack/doc/STM32Cube/General/html/cubemx.html The STM32Cube document above is too old for now and please update this document or give me some ideas to solve my problem. Thank you very much!
Have you tried using just RTOS(API)->Keil RTX? I have been playing around with some example code and when RTX5 is selected it produces the error "#81: more than one storage class may not be specified", but this disappears when the older RTX is selected instead.
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.
I had the same problem when i was working with Sdcard (MCI driver). My fix was to manually edit fs_os.h (remove its read-only flag first) . I don't know whether it'll work to USB driver or not, but here's what i added into fs_os.h :
// MOD, top line of the file after include "rl_fs_lib.h // ------------------------- #if defined(RTE_CMSIS_RTOS2) #define RTOS_DEFINED #undef RTE_CMSIS_RTOS #endif
// MOD, end of the file // --------------- #if defined(RTOS_DEFINED) #define RTE_CMSIS_RTOS #endif
hope it works for you.
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.