Using External Xtal causes a hardware exception

[RMyer.1]

Hi All,

I'm working with a STM32F303x8, when using the HSI as the clock I've found the timers drift too much between cold and hot running (which is fair), I'm seeing about a 0.3% drift which is an issue for this application.

I now have an 8MHz External crystal as the main clock and that appears to be working except I get a 'HardFault' after a few seconds of running. Switch back to the HSI and it's fine.

When the exception happens most of the time I am seeing the 'UNDEFINSTR' flag set (the processor has attempted to execute an undefined instruction) which makes no sense at all. If there was a bad instruction why would it happily execute off the Internal Clock and not hit this. So I'm not believing that as being the actual fault or my determination of that is wrong.

If I check the RCC status (SWS: System clock switch status) it says it is running off the HSE and HSERDY = 1.

The thing is when this exception happens the Timers are still generating an output signal, so the clock must still be functional. In fact I know it is the External Crystal still being used because my pulse outputs are dead accurate (unlike when running off the HSI).

Has anybody else run across anything like this before?

Thanks.

[ONadr.1]

Is RCC inetrrupt disabled? If enabled, is interrupt routine OK?

[TDK]

Does it happen if you use a lower clock speed? Does it happen at a specific location within the code?

[RMyer.1]

I have no RCC interrupts enabled.

[RMyer.1]

I have not tried a lower clock speed, I used an 8MHz crystal so it didn't matter if it was running off the internal or external clock source as all the timer calculations would be the same.

It doesn't seem to be in the same location in the code where it causes the exception unfortunately. But even if it was how could running off the External crystal vs Internal Clk cause that?

[waclawek.jan]

> But even if it was how could running off the External crystal vs Internal Clk cause that?

That's a good question, but unless somebody knows the answer, just pretend you've never tried HSI so you don't know there is a difference.

If there is external power circuitry controlled from the MCU, disconnect it.

Check power supply.

Try to debug as usually with HardFaults, i.e. look at the disasm a couple of instructions before the PC value stored on stack, and based on registers values judge what went wrong. Use mixed disasm/source view to see where in the source the problem occured.

JW

[Tesla DeLorean]

This is very odd. Wonder if something is glitching, or highly unstable.

Would suggest piping the clock out via MCO PA8 and scoping/monitoring that. Use a persistence mode.

Hard Faults could come from prefetch or flash wait states

[RMyer.1]

I didn't mention in my post that I am using a Nucleo-32 board, mounted in a socket on some prototype PCB so the XTAL (and load caps) aren't exactly right at the pins. Having said that it is as close as physically possible, but I agree I think there is an issue with the stability or quality of the clock.

A good idea to use the MCO option to try to pick a glitch.

[ONadr.1]

In this case you can use external 8MHz XT (TCXO) oscilator. There is no need it have to be near pins.

[RMyer.1]

Oh wow, I didn't even notice that ST-LINK STM32 had 8MHz on its MCO pin. I need to bridge the jumper on the board but that is a perfect solution, thanks.