Problem with CUBEMX 6.3 and CUBE F4 V26.2

Hello dear Engineers,

Before this upgrade(downgrade?????), I was able to use FREERTOS successfully. The main procedure was to change the time base from SYSTICK to TIM1 and then everything was working. Now in this upgrade even without FREERTOS, when the time base is set to any timer but SYSTICK, it gets stuck at  HAL_Init();.

The project is attached for further analysis. The board is a custom board.

sincerely yours

[Khouloud OTHMAN]

Hello @Vahid Ajallooeian​ 

Thanks for your feedback and for sharing your .ioc, but the issue isn't reproduced from my side.

As described in the HAL package, the HAL_Init function is used to initialize the HAL Library it must be the first instruction to be executed in the main program (before to call any other  HAL function).

Could you please debug again you code and step in the function ''HAL_Init'' to know where exactly it gets blocked?

Your feedback is important to track the root cause of the issue.

Thanks in advance,

Khouloud.

Dear @Khouloud OTHMAN​ 

Did you test the program on an STM32f429 series? I wonder if you have tested this issue on an MCU and if yes what was the MCU?

This issue is persistent even with the total removal of stm32f4 V1.26.0-.2 from the stm32cube program and hard disk and then redownloading it from the internet.

Dear @Khouloud OTHMAN​ 

The UC this time represents ​ strange behavior. It does cyclicly return to line 82 of "stm32f4xx_hal_timebase_tim.c" which is "return HAL_TIM_Base_Start_IT(&htim1);".

which is not really expected to return to this line but to continue to program.

Before it was looping in the zero bss filling part of .s startup file.

Moreover sometimes when I press pause on debug, it says "Break at address "0x1fff4f4c" with no debug information available, or outside of program code." which is in ccmram

In fact, if I return to F4 1.25.2 repository, everything would be okay. I think there is something with 1.26.0 until 1.26.2.

Dear @Khouloud OTHMAN​ 

Found some way to circumvent the issue. First I would generate the code with the 1.25.2 repository. Then I would regenerate the code with 1.26.2 and then the program goes on.

Sincerely yours.

Dear @Khouloud OTHMAN​ 

My problem also persists with Cubemx 6.4, CubeIde 1.8, and STM32f429IGT6. And one other thing. I have downloaded the F4 v1.26.0 package recently from this page. https://www.st.com/en/embedded-software/stm32cubef4.html. In the first place, the file size is broadcasted as 609 MB, but then it would download 624 MB. Can it be the source of the problem? Then I would add the repository by choosing the Help->Manage embedded software packages->MCU Packages-> V1.26.0.

Your help is really appreciated

After some debugging, I have found some issues.

While not using Freertos and systick as the time base, there would be no problem. But if you activate the Freertos and use one of the timers, for example, timer 1, it stucks in "HAL_InitTick(TICK_INT_PRIORITY);" since it has not been chosen to be as the time source. but the timer 1. I would suggest testing with a board with specifically STM32f429IGT6, not any other similar since it happens in this number, there is no problem for example with f407 discovery.

Dear @Khouloud OTHMAN (ST Employee)​ 

Here is the procedure to find that the problem is either in startup_stm32f429igtx.s or system_stm32f4xx.c (All in STM32CUBEIDE V1.8 and STM32CUBEMX 6.4)

First, initialize the project with the F4 V1.25.2 repository, everything works. Commit in the local git.

Second, regenerate the code with the 1.26.0 repository, everything works. Check the differences with git. The mentioned files didn't change. Commit the changes to git.

Delete all files except the .ioc file. Check if git works.

Third, generate the code with the 1.26.0 repository, code stocks at "HAL_InitTick(TICK_INT_PRIORITY);". Check the differences. Now it shows that two files have changed.

and they are "startup_stm32f429igtx.s" and "system_stm32f4xx.c". Mainly it stocks in "FillZerobss" and "LoopFillZerobss"

[TDK]

If you include your code, I can take a look. I'm not interested in spending 20 minutes regenerating a project which may or may not have the same bug as what you see.

The bug where TICK_INT_PRIORITY was set to an invalid value with a non-systick timebase was reported on another thread.

> Mainly it stocks in "FillZerobss" and "LoopFillZerobss"

These are fairly straightforward functions. It should be possible to examine registers to determine why it's not exiting, if that actually is the issue here, which I'm not convinced of.

Dear @TDK​ 

Thank you for your attention.

I have added 3 files to the top question.

The Working1 files are generated only with F4 1.25.2.

The Working2 files are generated first with F4 1.25.2 and then regenerated with 1.26.0.

The NotWorking files are generated only with 1.26.0.

And I wonder how to solve the TICK_INT_PRIORITY invalid value bug?

Sincerely yours

[TDK]

> And I wonder how to solve the TICK_INT_PRIORITY invalid value bug?

This isn't the thread I was thinking of, but it does explain the getting stuck in HAL_InitTick issue:

https://community.st.com/s/question/0D50X0000C6duTo/halnvicsetpriority-assert-issue-and-incorrect-preempt-priority-value-for-the-stm32f4-stm32g4-

@TDK​ @Khouloud OTHMAN​ 

The source of this problem is V1.26.0 "system_stm32f4xx.c" file.

The procedure I followed to find the source of the problem is as follows.

1) Only Replaced the "startup_stm32f429igtx.s" of V1.25.2 (Working1) to V1.26.0 (NotWorking), rebuild, debug --->>>> made no change. still not working. removed the debug folder, rebuild, debug --->>>> made no change. still not working.

2) Restored "startup_stm32f429igtx.s" of V1.26.0. Only Replaced the ""system_stm32f4xx.c" of V1.25.2 (Working1) to V1.26.0 (NotWorking), rebuild, debug --->>>> made no change. Still not working. Removed the debug folder, rebuild, debug --->>>> Now its working in the debug. The most important difference between these two files is in the external memory section.

[Khouloud OTHMAN]

Hello @Vahid Ajallooeian​ ,

First let me apologize for the somewhat late reply.

Actually, as far as I can see from what have been said, the issue is mainly related to the use of a time base other than Systick (tim1 for example).

To explain briefly the situation, starting from the firmware version STM32Cube_FW_F4_V1.25.0, The time base has been reworked in order to change dynamically the Timebase tick frequency (10, 100 and 1000 Hz) following the system frequency. To achieve this change the following functions have been already added in the stm32ynxx_hal.c:

• HAL_StatusTypeDef HAL_SetTickFreq(HAL_TickFreqTypeDef Freq)
• HAL_TickFreqTypeDef HAL_GetTickFreq(void)

In addition to the following exportable variables

• uint32_t uwTickPrio = (1UL << __NVIC_PRIO_BITS); /* Invalid PRIO */
• HAL_TickFreqTypeDef uwTickFreq = HAL_TICK_FREQ_DEFAULT; /* 1KHz */

When using only the default time base i.e. the systick, HAL_Init calls the first time HAL_InitTick(). Upon system clock change, the RCC_ClockConfig calls HAL_InitTick().

However, when using another time base, the HAL_InitTick is not correct: The priority is not stored:

HAL_Init calls the first time HAL_InitTick(), then the frequency of the time base will be changed by calling HAL_SetTickFreq(), and upon system clock change, the RCC_ClockConfig calls HAL_InitTick().

Focusing on the generated stm32f4xx_hal_timebase_tim.c file, the HAL_InitTick is not correct:

HAL_StatusTypeDef HAL_InitTick(uint32_t TickPriority) 
{
//....
/*Configure the TIM1 IRQ priority */
 HAL_NVIC_SetPriority(TIM1_UP_TIM10_IRQn, TickPriority ,0);
 
 /* Enable the TIM1 global Interrupt */
 HAL_NVIC_EnableIRQ(TIM1_UP_TIM10_IRQn);
//...
 
 /* Return function status */
 return HAL_ERROR;
}

And thus when calling the HAL_SetTickFreq(); this later will rather use the default prio (defined in the stm32f4xx_hal.c:( uint32_t uwTickPrio = (1UL << __NVIC_PRIO_BITS); /* Invalid PRIO */

The HAL_SetTickFreq() use a wrong Priority and the HAL hangs.

Unfortunately, CubeMX code generation wasn't updated to match this rework. this issue was reported internally to be fixed as soon as possible. I'll keep you posted with the updates.

Sorry for any inconvenience that this may cause.

To overcome this problem, please check stm32f4xx_hal_timebase_tim_template.c file delivered in the latest STM32Cube_FW_F4_V1.26 and edit HAL_StatusTypeDef HAL_InitTick (uint32_t TickPriority) function accordingly.

Hoping that I've answered your question.

Khouloud.

Dear @Khouloud OTHMAN​ 

Hope this will be solved in near future.

Sincerely yours.

Dear @Khouloud OTHMAN (Employee)​ 

It seems the ST F4 team doesn't want to solve this problem anymore. Yet it has not been solved in CUBE Micro Xplore 6.5 and F4CUbE 1.27.

Sincerely yours.