0

I've just bought an STM32 Nucleo board for my final project at university, specifically, it's the L4R5ZI-P board. I've downloaded the (STM32)CubeIDE and the MXCube,created a new STM32 project that's suited specifically for said board, with the peripherals set to their default values, with the exception of setting pin PA15 as GPIO_OUT. That pin wasn't set to anything before I've made this change.

Inside main.c I've added the following lines inside the superloop \ while(1) function -

HAL_GPIO_TogglePin(GPIOA, GPIO_PIN_15);
HAL_Delay(1000);

and connected PA15 to a LED on a breadboard.

When I debug the code, I can see that it gets caught in an infinite loop between HAL_GetTick() and HAL_Delay() More speficially -

__weak uint32_t HAL_GetTick(void)
{
  return uwTick;
}

and

__weak void HAL_Delay(uint32_t Delay)
{
  uint32_t tickstart = HAL_GetTick();
  uint32_t wait = Delay;

  /* Add a period to guaranty minimum wait */
  if (wait < HAL_MAX_DELAY)
  {
    wait += (uint32_t)uwTickFreq;
  }

  while ((HAL_GetTick() - tickstart) < wait)
  {
  }
}

And doesn't do anything besides that, zero led toggles, never reaches that part of code. Moreover, sometimes the line (which is inside main.c as well)

MX_SDMMC1_SD_Init();

gets the code stuck inside the error handler, doesn't happen all the time, but sometimes it does.

void Error_Handler(void)
{
  /* USER CODE BEGIN Error_Handler_Debug */
  /* User can add his own implementation to report the HAL error return state */
  __disable_irq();
  while (1)
  {
  }
  /* USER CODE END Error_Handler_Debug */
}

I can read the name of the init, which is referencing SD memory, but since I've created a clean\stock STM32 project for the L4R5ZI-P - I thought I was fine compiling it "as is", without needing to configure anything else. Was I wrong?

It's a very basic program, as you can see, I only wanted to make sure the board works by doing basic functionality tests.

  • Tried recreating a clean project, I thought maybe I did something wrong.
  • Searched online, and although I could find plenty of posts of users facing similar issue, no explanation was 'complete' enough for me to use, instead of making this post. I did find posts referring to NVIC and making sure the priority is set right, but for me - it's all set to 0 and I can't understand if that's an issue. I've added a photo of the values I see on the NVIC list.

Edit: After commenting out MX_SDMMC1_SD_Init(); HAL_Delay() works fine. This one is weird, because again, I'm using the board's default values, so it should be initialized correctly without any changes. I guess I should be doing some reading regarding this peripheral, because I don't get why it would fail (or why it is even on as a default value).

Saar
  • 1
  • 1
  • Does the value of `uwTick` change at all? If not, sounds like you've somehow disabled the sysTick interrupt. – pmacfarlane Mar 12 '23 at 15:12
  • uwTick has the value 7 and never changes for some reason. How can I tell if sysTick is disabled? – Saar Mar 12 '23 at 16:39
  • Can't edit my last comment, so I'm writing a new one. Where is HAL_IncTick() supposed to be called from? It's the function that's supposedly in charge of inceasing uwTick, right? I'll Google this one regardless of this comment. Wondering what's up with my board's configuration considering I haven't done anything apart from what I've stated in the initial post. – Saar Mar 12 '23 at 16:47
  • It's called from `SysTick_Handler()` in `Core/Src/stmxxxx_it.c`. The SDMMC peripheral will be enabled if you chose the "assign default pins" option when creating your project for the Nucleo board. And it will probably fail if there is no SD-card present. – pmacfarlane Mar 12 '23 at 18:09

0 Answers0