Problem with CUBEMX 6.3 and CUBE F4 V26.2

[Vahid Ajallooeian]

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.

[Vahid Ajallooeian]

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.

[Vahid Ajallooeian]

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.

[Vahid Ajallooeian]

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.

[Vahid Ajallooeian]

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

[Vahid Ajallooeian]

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.

[Vahid Ajallooeian]

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.

[Vahid Ajallooeian]

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