Associate III

Question

Using External Xtal causes a hardware exception

Forum|Forum|5 years ago
September 16, 2021
10 replies
2462 views

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.

STM32F3 series

This topic has been closed for replies.

ONadr.1

Senior III

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

RMyer.1Author

Associate III

I have no RCC interrupts enabled.

TDK

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

"If you feel a post has answered your question, please click ""Accept as Solution""."

RMyer.1Author

Associate III

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

Super User

> 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

Guru

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

Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..

RMyer.1Author

Associate III

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

Senior III

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

RMyer.1Author

Associate III

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.

RMyer.1Author

Associate III

As an FYI the tip offered by Tesla DeLorean helped, my scope measured (on the MCO pin) 7.99968 MHz when running off the HSE, and 7.975 MHz when running off the HSI, so that explains the issues I was seeing with the timer drift.

But I think my problem was maybe the External Crystal signal was not ideal and was causing the System Clock to be unstable when HSE was being used for SysClk.

Instead I now have the PLL clocked from the external crystal and the PLL becomes the SysClk. This has resulted in stable operation and the MCO pin (when the PLL is being switched to that output) is a rock solid 7.99968 MHz as well.

Then where ONadr.1 said to use the MCO pin from the ST-LINK STM32 on the Nucleo board I think I will ditch my external crystal and use that instead.

Thanks everyone for the replies.

Sign up

Login with SSO

Login to the community

Login with SSO