2020-01-28 03:33 AM
Hello,
I'm using STM32CubeMX 5.5.0 and Discovery board for STM32H747XIHx with FreeRTOS. FreeRTOS uses system tick timer and I use TIM7 as Timebase source, but this issue happen also if I use other timers then TIM7. When my *.ioc project is opened and I set TIM7 as Timebase source than I can see "Time base: TIM7 global interrupt" line in NVIC1->Code generation and I can enable to generate IRQ and HAL handler. The problem is when I close the *.ioc file in IDE and open it again (or when I open my whole project) then this line is missing and CubeMX won't generate interrupt or timer handler if I click on generate code button. If I want to have that line in NVIC1->Code generation again, I have to change the Timebase source in SYS to another timer and change it back to my TIM7, than I can see that line in NVIC1->Code generation again and the code is generated correctly.
Update: I forgot to mention that sometime also "Call HAL handler" option for "USB On The Go HS global interrupt" in NVIC1->Code generation automatically uncheck from some reason and I have to troubleshoot the code to find out that the HAL handler is not called from interrupt routine.
Thanks,
Petr
2020-01-28 04:26 AM
Hello @PHlin.1 ,
This will be internally checked.
Best Regards,
Khouloud
2020-01-28 05:32 AM
Issue will be fixed in the next release @PHlin.1 , thanks for your feedback.
Best Regards,
Khouloud
2020-06-05 02:18 AM
I started writing the below as a new topic having not been able to find an related issues but then realised my search term was a bit off.. having found this report I have instead moved the report to here as i think it is very much related.
Previously configured IRQ Handlers disappear when change other settings and re-generate code.
Example..
New project,
* STM32H745ZITx
* Sys->Timebase Source to TIM17,
* FreeRTOS middleware enabled (may or may not be relevant)
Generate code, observe content of stm32h7xx_it.c, it contains
/**
* @brief This function handles TIM17 global interrupt.
*/
void TIM17_IRQHandler(void)
{
/* USER CODE BEGIN TIM17_IRQn 0 */
/* USER CODE END TIM17_IRQn 0 */
HAL_TIM_IRQHandler(&htim17);
/* USER CODE BEGIN TIM17_IRQn 1 */
/* USER CODE END TIM17_IRQn 1 */
}
Now configure another peripheral (e.g. SPI1) and enable DMA, (tho configuring plenty of other things also leads to the same problem). Generate code and check back in the above file, the above handler is now missing. One has to toggle to a different tim for Timebase and back again and then generate code again for it to re-appear. This is very frustrating. The symptoms when running a project where this is happening is that the code get stuck in the infinite loop of Default_Handler in startup_stm32h745zitx.s.
The above are just an example, I don't think it is no only the Timebase TIM handler that can disappear, and not only configuring an SPI peripheral that causes the disappearance, I think I had problems with the USB handlers disappearing when I was working on a USB project some months ago but it is possible configuring the USB peripheral was making the Timebase TIM or another IRQ handler disappear, i cant recall for sure,
I can't find any other reports of this happening but a colleague is seeing the exact same behaviour so its not just me!
This is surely a bug in the CubeMX code generator and specific to either this MCU or s subset of the whole family as I have not had this problem on other parts (e.g. stm32f407 , stm32f105, stmf32f746 .. and a few others).
I am using CubeIDE 1.3.1 (CubeMX 5.6.1.202004052303) and all the latest FW packages. This issue has been present ever since I started using CubeIDE and the NUCLEO-144 with this part (end of last year), i.e. over several updates, each of which i have hoped will fix it and have failed to do so.
Note, Prior to use CubeIDE I had been using CubeMX standalone for some years with the other mentioned MCU's and hadn't encountered this problem before.
2020-07-02 01:50 AM
Probably my problem is related to this topic. Sometimes code generation forgets some function headers. It usually does it after changing some DMA settings, but not sure, when exactly, hard to reproduce, but here is an example:
/**
* Enable DMA controller clock
*/
{
/* DMA controller clock enable */
__HAL_RCC_DMA1_CLK_ENABLE();
/* DMA interrupt init */
/* DMA1_Stream0_IRQn interrupt configuration */
HAL_NVIC_SetPriority(DMA1_Stream0_IRQn, 0, 0);
HAL_NVIC_EnableIRQ(DMA1_Stream0_IRQn);
/* DMA1_Stream1_IRQn interrupt configuration */
HAL_NVIC_SetPriority(DMA1_Stream1_IRQn, 0, 0);
HAL_NVIC_EnableIRQ(DMA1_Stream1_IRQn);
}
Probably related to the same bug. Hopefully will be get fixed in the next update.
2021-12-23 06:09 PM
Any updates on this issue? I've just started seeing it occur. Is there a good workaround?