READ_BIT(RCC->CR, RCC_CR_HSERDY) fails with a HAL_TIMEOUT when running blinky in debug.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-09-23 10:04 AM - edited ‎2024-09-23 3:00 PM
While in debug I get and error in this line of code. I do not get an error when running code not in debug.
/* Wait till HSE is ready */
while (READ_BIT(RCC->CR, RCC_CR_HSERDY) == 0U)
{
if ((HAL_GetTick() - tickstart) > HSE_TIMEOUT_VALUE)
{
return HAL_TIMEOUT;
}
}
SBC NUCLEO-U5A5ZJ-Q
CUBEMX IDE
- Labels:
-
RCC
-
STM32CubeMX
-
STM32U5 series
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-09-23 10:10 AM
It takes too long, or the HSE is not present / connected.
Check board level jumper or solder-bridges (SB)
Clock typically derived from MCU providing ST-LINK, the frequency and presence of this can be changed/disabled
Check the HSE is populated, or wired to another source.
Check Systick isn't clocking faster than anticipated.
Up vote any posts that you find helpful, it shows what's working..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-09-23 10:24 AM
I left out on detail it works fine when I run it but fails when I am trying to debug it
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-09-23 11:10 AM
Humans run more slowly..
Are you single-stepping this?
Check DBGMCU settings/options, if it is allowing interrupts to continue whilst stopped? How is HAL_Delay() / HAL_GetTicks() implemented in your build?
Up vote any posts that you find helpful, it shows what's working..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-09-23 11:21 AM
No that would take forever. I have used break points to find where the error is set. I increased the HSE time out to 10000 so it should be plenty of time.
Start in debug. Hit continue. It runs and then hits a breakpoint on the return a time_out.
No single stepping was used in the creation of this issue.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-09-23 1:01 PM - edited ‎2024-09-23 2:48 PM
Is your clock set to HSE bypass? That is the default on nucleo boards, without modifying solder bridges.
Edit: it is the default on some boards, but, importantly, not this one.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-09-23 2:09 PM
Yes it is.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-09-23 2:35 PM
Some Nucleo boards have "HSE not used" as the default solder bridge configuration; for example, Nucleo L4XX.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-09-23 2:47 PM - edited ‎2024-09-23 2:50 PM
@Chris21 Thanks for the correction.
@lwatcdr It looks like on the NUCLEO-U5A5ZJ-Q, the 16 MHz crystal is hooked up by default, so HSE selection should be 16 MHz, non-bypass. Looks like CubeMX sets it to 8 MHz bypass by default for this board.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-09-23 3:04 PM
I have two questions
- So why does it fail only in debug but when I run not in debug.
- Where do I set the HSE to 16Mhz.
