LSE Clock Output Missing Pulses on NUCLEO-F767ZI

[MPatt.11]

I used STM32CubeMX to build a very simple test case to output both the High Speed Clock (HSE) and Low Speed Clock (LSE) on output pins. I selected "Master Clock Output 1" and Master Clock Output 2" when I configured the input clocks. The HSE clock has Bypass clock source selected since the Nucleo has a clock input and not a crystal on that pin. The LSE clock is configured for Crystal since there is a crystal on the pins.

When I put a scope on the HSE output (PC7) everything looks normal. When I put the scope on the LSE pin (PA8), I see pulses missing. Sometimes the signal gets stuck high, sometimes it is stuck low. It looks like there is one pulse missing in each case. When low, the pulse on either side of the missing pulse is chopped off. This happens about every 1 ms.

I have a few scope screen captures that I've attached.

Does anyone know if this is normal? It seems very odd that pulses from a crystal would be missing.

[waclawek.jan]

This is indeed very strange.

Did the Nucleo board come with the 32.768kHz crystal already mounted, and if yes, did you modify anything on the circuitry around it? Do you have anything connected to the board except the scope probes? Is there any program running? Do you see any activity on the NRST pin?

> HSE output (PC7)

PC7? There's no MCO functionality on PC7; there is on PC9 (MCO2 as AF0). Please explain

JW

[MPatt.11]

Thanks for the response. You got me thinking about a few things to try.

Yes, the crystal came installed. I have not modified anything on the board except to add some headers on the open IO pins on the edge. I am running a program to configure the clocks, then go into an infinite loop. The program is running out of the on-chip RAM with the debugger running. Systick is running also.

I programmed the code into Flash, with the same results. I reset with the debugger disconnected with no difference. I tried this on a different identical Nucleo with the same results. I looked at other configuration issues and turned off Semihosting which I was not using anyway, still running out of Flash. This resolved the issue. Then I turned semihosting back on and the issue did not come back. Then, I configured the code to run out of RAM again, and the problem did not return.

I don't know what the issue was, but I cannot seem to get it to return at the moment. I'm going to build this from scratch again and see if the problem returns. Hopefully I can narrow down exactly what caused this to start in the first place. I'll update this when I've come closer to figuring this out.

[Tesla DeLorean]

Might we ask what tool chain and debugger you are using here?

I'd be wary of the settings in DBGMCU and if they cause the stall when they probe the device.

Bit 10 DBG_RTC_STOP: RTC stopped when Core is halted

0: The RTC counter clock continues even if the core is halted

1: The RTC counter clock is stopped when the core is halted

[MPatt.11]

I am using Visual Studio 2017 (GCC) with VisualGDB as the debugger. I have Segger J-Link loaded into the on-board chip replacing ST Link, and the VisualGDB is connected through the on-board USB interface. The board is powered though the same USB interface. So far, this configuration has worked flawlessly.

Earlier I tried running from Flash with the debugger not running and it still did the same thing. On the Nucleo, the debugger is running in a separate chip so I don’t think it is possible to really physically disconnect it.  

[MPatt.11]

I have just discovered something that may explain this. I started having issues with the LSE clock not running at all, then other times is will run. Just as an idea, when it was not running, i used my finger to touch the area around the crystal. The clock started running and kept running. When I restarted the code, it started running again.

I think the crystal is not starting to oscillate, or oscillate properly. Since I've seen this issue on two different Nucleo boards. I'm not sure yet if this is a temperature issue or what exactly. Now that I know what it is, I have heard that putting a very large resistor across the crystal can prevent issues like this. I'll do more checking. I may need to implement this on my final board if this is an issue with the STM32F7, or not if it is an issue with this particular crystal. The HSE does not have this problem.

[waclawek.jan]

The crystal oscillator is ought to consume as little power as possible (as it is designed to run out of a battery for long time) thus is a low power circuit. Low power implies high impedances. Think of tens of MOhms. Your finger as around 10kOhm.

Don't ever touch running electronics, this is a general rule.

JW