NUCLEO-U575ZI-Q - HAL_GetTick returns 0

[CLC_EricF]

Bonjour,

J'utilise la suite CUBEMX et CUBEIDE  pour créer mon projet à partir d'une carte de développement NUCLEO-U575ZI-Q.
J'ai réalisé mon projet sur CUBEMX en gardant et validant le BSP de la NUCLEO pour utiliser les leds et surtout le debug via ST-LINK embarqué.

J'ai ajouté des IO pour effectuer une maquette avec SPI1 et OCTO-SPI1 plus quelques IO notamment une PWM.

Pour commencer j'ai d'abord réalisé un bout de code pour faire clignoter une led (LED_GREEN); à une certaine fréquence réglée par HAL_Delay.

Le souci est que cette fonction bloque car le Tick ne semble pas être validé, (HAL_GetTick  me retourne toujours 0)...

Je crois pourtant avoir validé les interruptions :

Hello,

I am using the CUBEMX and CUBEIDE suite to create my project based on a NUCLEO-U575ZI-Q development board.
I created my project on CUBEMX, keeping the NUCLEO BSP to use the LEDs and, above all, debugging via the embedded ST-LINK.

I added I/Os to create a model with SPI1 and OCTO-SPI1, and a few I/Os, including a PWM.

To start with, I wrote a piece of code to make a LED (LED_GREEN) flash at a certain frequency set by HAL_Delay.

The problem is that this function blocks because the tick does not seem to be validated (HAL_GetTick always returns 0)...

However, I believe I have validated the interrupts:

Translated with DeepL.com (free version)

Can you help me, je débute dans l'environnement STM32CUBE...
Thanks in advance,

Eric

 

[mƎALLEm]

Hello @CLC_EricF and welcome to the ST community, 

Check if the option to generate the system tick interrupt handler code is checked in the code generation tab:

[StevenG]

Eric,

  Somewhere within your project (usually main.c) you should have a function similar to the following:

/**
 * @brief Period elapsed callback in non blocking mode
 * @note This function is called when TIM6 interrupt took place, inside
 * HAL_TIM_IRQHandler(). It makes a direct call to HAL_IncTick() to increment
 * a global variable "uwTick" used as application time base.
 * @PAram htim : TIM handle
 * @retval None
 */
void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim)
{
 /* USER CODE BEGIN Callback 0 */

 /* USER CODE END Callback 0 */
 if (htim->Instance == TIM6)
 {
 HAL_IncTick();
 }
 /* USER CODE BEGIN Callback 1 */

 /* USER CODE END Callback 1 */
}

In my case I am using TIM6 to create the time base used by HAL_GetTick().  Make sure you have similar code in your application and maybe place a breakpoint on the line with HAL_IncTick() to make sure your code is getting to this point.  NOTE:  in general I always use a timer to create the system clock so I am not sure what happens if you use the SysTick. 

 

You mention that you created your project based on the NUCLEO board.  Are you running code on a NUCLEO board or on hardware you designed and built?  The NUCLEO board appears to have on-board HSE and LSE crystals/oscillators.  If you have designed a board without HSE or LSE clock sources, your code will need to use only the internal RC oscillators. 

 

The HAL code often doesn't implement fail-safe operation and will enter code loops waiting for a bit to be set/cleared without any kind of timeout.  Of course, if you are using an actual NUCLEO board, you shouldn't have a problem with this type of issue.

[CLC_EricF]

Thanks  @mƎALLEm and @StevenG  for your responses.

 @mƎALLEm : Yes the option to generate the system tick interrupt handler code is checked in the code generation tab:

 @StevenG :No, I didn't have the function implemented in main.c, I added it by synchronizing it with TIM1 declared as OutputCompare. It doesn't go into any interrupt.
And HAL_GetTick always returns 0...
Best Regards,

Eric

[mƎALLEm]

Hello,

Thank you for the confirmation,

Could you please attach your project so I could reproduce the case in the next week as I don't have that board for now?

[CLC_EricF]

Thank you for your proposal. !

[CLC_EricF]

Hello,

So I ran an example (GPIO_Demo.ioc) without touching the .ioc file (just generating the code with CubeMX and compiling and debugging it in CubeIDE).
Naturally, everything works: Get_Tick, HAL_Delay, and EXi interrupts.
Now I'm going to try to compare the two projects (mine in Secure-NoSecure mode) and the demo to try to understand what I'm missing.
I already notice that in the demo's ioc file, neither the NUCLEO board's BSP nor DEBUG are validated in the file, so everything is done by code?

I admit this confuses me a little...

Regards,

Eric

[mƎALLEm]

Hello,

Sorry I'm not sure to follow you.

Did you test a simple project without TrustZone or not? if yes what was your finding?

[CLC_EricF]

Hello @mƎALLEm ,

Yes, I tested a simple project taken from the examples provided by ST for the NUCLEO-U575 board, without TrustZone. It is the GPIO_Demo code, which I had already used as inspiration, but I created my own configuration by adding TrustZone and the I/O for the SPI and octo-spi outputs so that I could control the screen and the QSPI flash on my future prototype.
The demo works well without TrustZone.

When I look at the GPIO_Demo.ioc project on CubeMX, I see, for example, that neither the debug interface nor the Nucleo board's BSP are validated, even though I validated them in my CubeMX project.
The clock configuration is the same.

Extract from GPIO_Demo.ioc :    Extract from my project :

     

The pinouts view of the two projects:

          my project : 

 

 

I used to work on Renesas Synergy with the BSP suite in e2studio, where everything could be configured graphically. I think it's the same here with cubeMX, but the example project doesn't really demonstrate this.
I think I have a lot to learn; the transition seems more complicated than I thought.
Eric