2022-05-11 05:40 AM
Dear all,
I am using Cube MX to generate a template code for my new project. In Advanced Settings page under project manager tab, Init sub-routines order is not correct and I also cannot fix it. DMA is used in ADC1 and it should initialize before than ADC1_Init. However Cube MX puts ADC1_Init function before than DMA_Init. MX_ADC1_Init order also cannot be changed because order change buttons are not active.
There is a problem with RCC section as well. I reported previously and ST said it is known issue and will be fixed. (https://community.st.com/s/question/0D53W00001Xuay2SAB/adc-clock-setting-in-st-cube-mx-for-stm32h742vgt). However I may find another problem. I genereted a template code using Cube MX and I realized some peripherals clock and PLLs are not set in PeriphCommonClock_Config subroutine. I am not sure whether it is a mistake but I believe it is. There is only settings for PLL3 and SPI123. I am using PLL2Q and some USARTs. Do you think it is a mistake and cube mx should generate code for other PLLS and USARTs as well?
Best Regards
Solved! Go to Solution.
2022-05-11 07:20 AM
Hello @TA ,
Thanks for your feedback,
About the DMA init order, it is known issue, it was partially fixed in 6.5.0 and there are still some cases (such as migrating an ioc) where the order is not corrected. The dev team is working on it and it will be properly fixed soon.
The DMA order can be corrected manually from Project Manager view > Advanced Settings tab as explained in this thread.
As for the Clock init, only peripherals using PLL2, PLL3, PLLSAI1, PLLSAI2 as a source clock are configured in PeriphCommonClock_Config() and only when they are used by more than one peripheral. Otherwise the clock init will be generated in HAL_IPNAME_MspInit or in MX_IPINSTANCE_Init.
For USART1,6 for example, the peripheral clock is PCLK2 so it is configured in HAL_UART_MspInit in stm32h7xx_hal_msp.c file.
PeriphClkInitStruct.PeriphClockSelection = RCC_PERIPHCLK_USART1;
PeriphClkInitStruct.I2c3ClockSelection = RCC_I2C3CLKSOURCE_PCLK2;
However, SPI2 and SPI3 share the same Clock mux and it is set to PLL3, so the clock config is done in PeriphCommonClock_Config() in main.c file.
PeriphClkInitStruct.PeriphClockSelection = RCC_PERIPHCLK_SPI2|RCC_PERIPHCLK_SPI3;
Saying that only SPI2 is enabled and only its clock mux is set to PLL3, the clock init will not be generated in PeriphCommonClock_Config(), instead it will be generated in HAL_SPI_MspInit()
In case SPI4,5 clock mux is changed to PLL2Q, this source clock will be used by SPI4,5 and USART2,3,4,... so the clock init will be generated in PeriphCommonClock_Config().
I hope this helps and If you have further question, don't hesitate to ask :smiling_face_with_smiling_eyes:
If your issue is solved, please close this post by clicking the "Select as Best" button. This will help other members of the community find this response more quickly :)
Sara.
2022-05-11 07:20 AM
Hello @TA ,
Thanks for your feedback,
About the DMA init order, it is known issue, it was partially fixed in 6.5.0 and there are still some cases (such as migrating an ioc) where the order is not corrected. The dev team is working on it and it will be properly fixed soon.
The DMA order can be corrected manually from Project Manager view > Advanced Settings tab as explained in this thread.
As for the Clock init, only peripherals using PLL2, PLL3, PLLSAI1, PLLSAI2 as a source clock are configured in PeriphCommonClock_Config() and only when they are used by more than one peripheral. Otherwise the clock init will be generated in HAL_IPNAME_MspInit or in MX_IPINSTANCE_Init.
For USART1,6 for example, the peripheral clock is PCLK2 so it is configured in HAL_UART_MspInit in stm32h7xx_hal_msp.c file.
PeriphClkInitStruct.PeriphClockSelection = RCC_PERIPHCLK_USART1;
PeriphClkInitStruct.I2c3ClockSelection = RCC_I2C3CLKSOURCE_PCLK2;
However, SPI2 and SPI3 share the same Clock mux and it is set to PLL3, so the clock config is done in PeriphCommonClock_Config() in main.c file.
PeriphClkInitStruct.PeriphClockSelection = RCC_PERIPHCLK_SPI2|RCC_PERIPHCLK_SPI3;
Saying that only SPI2 is enabled and only its clock mux is set to PLL3, the clock init will not be generated in PeriphCommonClock_Config(), instead it will be generated in HAL_SPI_MspInit()
In case SPI4,5 clock mux is changed to PLL2Q, this source clock will be used by SPI4,5 and USART2,3,4,... so the clock init will be generated in PeriphCommonClock_Config().
I hope this helps and If you have further question, don't hesitate to ask :smiling_face_with_smiling_eyes:
If your issue is solved, please close this post by clicking the "Select as Best" button. This will help other members of the community find this response more quickly :)
Sara.
2022-05-12 08:12 AM
Dear Sara
Thank you very much your reply. First solution won't work for me because I don't have older version of ioc file. But ok I will change inside C code for now.
I will check PLL settings in C code as well. So it is not a mistake and It is good to hear that.
Best Regards
2022-05-13 03:50 AM
Dear Sara
I re-created a Cube Mx project and DMA order problem is solved as you explained in other threat. However I realized another issue may be it is known issue but let me report.
In clock configuration page, IWDG Timer block is not seen. I though it is caused by migration from previous version and I checked while I was re-creating the project and I thought I would be right because IWGD Timer block was seen in the page. I saved and re-opened the project but it disappered again.
Other things is about SPI global interrupt in SPI Settings--> NVIC sub settings. I cannot disable SPI global interrupt because check box is not active. I am not sure if it is a problem or not. I suspect from everything because I have faced many problems in V6.5.0. I have an old project for STM32F745 and SPI global interrupt can be disabled in NVIC settings. Therefore I suspect about it.
Regards,
2022-05-13 05:20 AM
Hello @TA ,
Thanks for sharing your findings, I confirm the IWDG clock issue. It seems that the ioc migration caused the disappearance of the IWDG clock.
About the SPI, I still couldn't reproduce the issue. I need more details about it.
Since this thread is closed, Could you please create two new threads for the SPI and IWDG issues, We will resume our discussion there. It will also help community members who might be facing the same issue to get their answer faster.
Could you please attach your ioc for the SPI issue and add the links of the new threads in a comment here.
Thank you,
Sara.
2022-05-13 09:16 AM
Dear Sara
I opened two new threats and here is the link.
https://community.st.com/s/feed/0D53W00001YaTb8SAF for IWDG Timer Blcok
Regards
2022-06-29 05:04 AM
Hello @TA ,
The issue regarding the DMA init order is fixed in STM32CubeMX latest release.
V6.6.0 is now available under this Link.
Thanks for your contribution.
Sara.
2022-07-01 04:36 AM
Dear Sara ,
I have a project for STM32F745VGE and I downloaded latest version after your information and I migrate the project and DMA order problem still exist. There is a solution about migaration which is explained by another ST Employee, and her advice worked before. I will try her advice and I hope it will work for the latest version.
2022-07-04 01:26 AM
Hello @TA ,
From which version did you migrate the project and was the DMA init order correct before project migration ?
If you still have a copy of your old ioc, could you please share it with me?
Sara.
2022-07-04 04:11 AM
Dear Sara
It is from 6.5 to 6.6. To be honest, I don't know whether the DMA init order correct before project migration. However it was made with 6.5. I didn't migrate. I supposed that it was ok. I followed suggestion explained in "https://community.st.com/s/question/0D53W00001EzCmCSAV/mxdmainit-order-in-the-mainc-file-generated-by-stm32cubemx-how-to-fix" the link and it worked.
I don't have old ioc. If I face similar problem with other project, I will let you know.
Regards