2019-09-30 09:31 PM
Using STM32Cube, I can build the demo project MOTENV1_IKS01A3_WB55RG fresh from the zipfile fine.
However, you cannot open the MOTENV1_IKS01A3_WB55RG.ioc file in it's original location. You get and error that it is the wrong name.
So I copy MOTENV1_IKS01A3_WB55RG.ioc from the MOTENV1 directory , into the MOTENV1/STM32CubeIDE/MOTENV1_IKS01A3_WB55RG directory. (where it should be)
But if I open it there, make no changes and and regenerate the code, I get numerous errors. The first is: motenv_stm.c:149:3: error: unknown type name 'MOTENV_STM_App_Notification_evt_t'; did you mean 'EDS_STM_App_Notification_evt_t'?
Diffing against the previous directory shows numerous changes. Looking at just the .ioc file when opened with CUBE, these lines are different:
188,189c188,189
< ProjectManager.CustomerFirmwarePackage=..\\..\\..\\..
< ProjectManager.DefaultFWLocation=false
---
> ProjectManager.CustomerFirmwarePackage=
> ProjectManager.DefaultFWLocation=true
208,209c208,209
< ProjectManager.UnderRoot=false
< ProjectManager.functionlistsort=1-MX_GPIO_Init-GPIO-false-HAL-true,2-MX_DMA_Init-DMA-false-HAL-true,3-SystemClock_Config-RCC-false-HAL-false,4-MX_LPUART1_UART_Init-LPUART1-true-HAL-false,5-MX_USART1_UART_Init-USART1-true-HAL-false,6-MX_RF_Init-RF-false-HAL-true,7-MX_RTC_Init-RTC-false-HAL-true,8-MX_CRC_Init-CRC-false-HAL-true,9-APPE_Init-STM32_WPAN-false-HAL-true,10-MX_MEMS_Init-STMicroelectronics.X-CUBE-MEMS1.6.2.0-false-HAL-true,11-MX_MEMS_Process-STMicroelectronics.X-CUBE-MEMS1.6.2.0-false-HAL-true
---
> ProjectManager.UnderRoot=true
> ProjectManager.functionlistsort=1-MX_GPIO_Init-GPIO-false-HAL-true,2-MX_DMA_Init-DMA-false-HAL-true,3-SystemClock_Config-RCC-false-HAL-false,4-MX_LPUART1_UART_Init-LPUART1-true-HAL-false,5-MX_USART1_UART_Init-USART1-true-HAL-false,6-MX_RF_Init-RF-false-HAL-true,7-MX_RTC_Init-RTC-false-HAL-true,8-MX_CRC_Init-CRC-false-HAL-true,9-APPE_Init-STM32_WPAN-false-HAL-true
350a351
> isbadioc=false
So it appears this file is useless with STM32Cube. Is this an instance of " Importing the ioc file created by stand-alone STM32CubeMX is not fully supported."?
If I wanted to use this example for the basis of a project, what would be a workable method?
Solved! Go to Solution.
2019-10-08 07:00 AM
Ok. When starting from an .ioc file to create a project, you have to use CubeMX tool.
One constraint: The name of the directory where the .ioc file is located must have the same name as the one of the .ioc file (without ioc of course).
Then it could be opened with CubeIDE.
We already got a request to be able to open a project with CubeIDE starting directly from the .ioc file. We are working on this. I can’t tell you when it would be available.
2019-10-04 09:18 AM
@Remi QUINTIN , this has been open a few days. Can I get some feedback? I need to be able to remap some IO like I2C so I can use the QSPI, but this is blocking me.
2019-10-07 12:31 AM
>MOTENV1_IKS01A3_WB55RG fresh from the zipfile fine.
Could you tell me or point me to the location where you get the zip file of this project?
2019-10-07 09:22 AM
Then open: STM32CubeFunctionPack_MOTENVWB1_V1.0.0\Projects\P-NUCLEO-WB55.Nucleo\Applications\MOTENV1\STM32CubeIDE
2019-10-08 07:00 AM
Ok. When starting from an .ioc file to create a project, you have to use CubeMX tool.
One constraint: The name of the directory where the .ioc file is located must have the same name as the one of the .ioc file (without ioc of course).
Then it could be opened with CubeIDE.
We already got a request to be able to open a project with CubeIDE starting directly from the .ioc file. We are working on this. I can’t tell you when it would be available.
2019-10-08 03:55 PM
OK, so I just renamed the .ioc file without moving it, and use CubeMX, not CubeIDE for now. Comparing the source results in quite a few changes, because the generator has been updated, but at least they compile. Thanks.