why can't I change the clock

[DBecc.1]

I inherited someone else's code who knows more about the STM32L1 architecture than I. In some code paths, the HSI can get changed to 8Mhz from the HSE of 32Mhz, and sometimes it can't.

It fails because of this loop timing out.

do {
	HSIStatus = RCC->CR & RCC_CR_HSIRDY;
} while ( (HSIStatus == 0) && ( HAL_GetTick() < timeout ) );

What might be blocking the HSI from being ready? Any thoughts on what things I might enable or disable in order to get the HSI status to be ready all the time?

[Tesla DeLorean]

The HSI has not been enabled, or some external thread (interrupt/callback) turns it off.

Check, report, the content of the RCC->CR word in the failing context.

[DBecc.1]

These are the preceding lines to this while loop

RCC_APB2PeriphClockCmd( RCC_APB2Periph_SYSCFG, ENABLE ); /* Enable the clock on the SYSCFG */
RCC_HSICmd( ENABLE );
RCC_HSEConfig( RCC_HSE_OFF );
RCC->CR |= ( ( uint32_t )RCC_CR_HSION );

I'll go look at RCC->CR's value and post that momentarily.

[Tesla DeLorean]

Check also the code generated, and that the read of RCC->CR is done like it's volatile.

The registers typically have a __IO type which should be volatile, but if you've used some other libraries, or the compiler broke, this might not be happening.

[Tesla DeLorean]

Also you're turning off HSE, what's running the MCU in this state, MSI, PLL via MSI ?

[DBecc.1]

Whoops... it *was* working after all. It was some other logic that was failing. Sorry to waste your time on this. But thanks for helping

[Tesla DeLorean]

No worries, half the process is reviewing the code, and rechecking the flow.