Starting MCO clock in STM32G474 without runt pulses

[uer166]

We've discovered an errata condition in an ADC where if there is a high-frequency runt pulse on the MCO clock that feeds its' main clock input, it craps out forever until a full power cycle. Now, I've been trying to find a way to start the MCO (fed from HSE input) with a nice rising edge and a full 1/8MHz cycle without any runt pulses. The only option that I see revolved around using a timer's input capture to generate an interrupt on a HSE/32 rising edge, and turn on the MCO output.

Alternatively, just use a busy-wait loop on the input capture flag and "sync" the executing code to the HSE/32, and enable MCO at a convenient location. So far, nothing seems to work due to execution, or some other kind of jitter. Best I could do is about 43ns jitter, or 6-7 cycles at 160MHz. I've tried some bare minimum code so that there's no DMA fighting for bus access. I've tried disabling caches. I've counted the disassembly cycles. So far, absolutely nothing seems to bring that jitter down. To make this workable I need to have <20ns jitter in enabling the MCO.

The datapaths are quite complicated, but really I don't see any reason for 6+ cycles of jitter between all the AHB/APB bus and peripheral accesses in the bare minimum code. If there is any alternate way to start this damn clock nicely, I'd like to know too.

[uer166]

Oh, I've also tried starting it with a large divider ratio (slow clock), and changing divider to 1. But in the attached pic the runt pulse is still there sometimes so obviously that didn't help. For reference, HSE in my case is 8MHz, main CPU/peripherals clock is 160MHz from the PLL which is fed from that same 8MHz HSE clock.

[errorprone]

Any possibility of using a timer instead of the MCO? The timers period can be double buffered so updates only happen on an edge which should help with the partial pulse.  Aside from that, jitter should be better if move everything to CCM.  I’m thinking it might be the flash wait states that is causing the jitter. If you do use CCM with interrupts just remember to remap the IVT in addition to the interrupts handlers.

[uer166]

Good thought but unfortunately I'm using all the timer outputs on PA8. I'm currently trying to coerce the I2S peripheral to output a clean 8MHz MCLK.

[harerod]

...

Alternatively, just use a busy-wait loop on the input capture flag and "sync" the executing code to the HSE/32, and enable MCO at a convenient location. So far, nothing seems to work due to execution, or some other kind of jitter. Best I could do is about 43ns jitter, or 6-7 cycles at 160MHz. I've tried some bare minimum code so that there's no DMA fighting for bus access. I've tried disabling caches. I've counted the disassembly cycles. So far, absolutely nothing seems to bring that jitter down. To make this workable I need to have <20ns jitter in enabling the MCO.
...

This would have been my approach. Note, I am not familiar with the G4, my workhorses are the first generation F4. Some thoughts:
I was going to recommend coding the sequence in assembly. Since you already counted disassembly cycles, this might not help. I don't know the clock tree of the G4. On the F4 there would be several possible causes for your jitter:
- the PLL is jittery like hell, it even may introduce a spread spectrum, to reduce peak EMI at its working frequencies
- the code runs from PLL, the MCO directly from the HSE, right?
-> could you run the whole device, incl. CPU and peripherals from HSE without PLL to perform the switch? And then you spool up the CPU to full PLL speed while maintaining MCO?

[uer166]

-> could you run the whole device, incl. CPU and peripherals from HSE without PLL to perform the switch? And then you spool up the CPU to full PLL speed while maintaining MCO?

This is the best advice so far! While the i2s solution worked, it turns out i2s is actually the SPI2 peripheral which I already use. I do wonder though, the STM32 has many clock domains inside with syncing and re-syncing, so even with the CPU and all peripherals running from same clock, is a runt-less MCO turn-on guaranteed? It sure seems to work really well on the scope, but this is one of those 1/100 unit issues that happens once in a while..

[harerod]

"This is the best advice so far!" Thank you. Not much else to say, without having more information. Would you mind sharing the ADC model? The whole schematic section would be even more helpful.

"...so even with the CPU and all peripherals running from same clock, is a runt-less MCO turn-on guaranteed?"
Guaranteed? If it is neither in the Datasheet, Programming Manual nor in the Errata - no.
However, if the whole device runs from the same clock, the only possibility for runt pulses would be race conditions in those long logic/clock chains that you already mentioned. So if it works once, you should be fine.


I don't get your last sentence:
"It sure seems to work really well on the scope, but this is one of those 1/100 unit issues that happens once in a while.."
Do you have encountered problems after clocking the whole device directly from HSE or not? You might have some trigger option on your oscilloscope which would show runt pulses.

[uer166]

"It sure seems to work really well on the scope, but this is one of those 1/100 unit issues that happens once in a while.."

What I meant is, it's hard to test this kind of problem because even in the original case, only some power-ups resulted in runt pulses, but some didn't. It makes it hard to verify a solution since a small sample size of devices isn't proof that the solution actually works.

This is MCP3914 ADC, I'm battling multiple both documented and undocumented errata conditions, including a new one I discovered. A lot of those issues have mutually exclusive workarounds (like you fix one errata but break another), so it hasn't been easy. This runt pulse problem wouldn't be a problem if it wasn't for an unrelated errata with a broken POR circuit (sub-threshold operation at 0.2-0.6V can corrupt and disable it in some once-in-a-blue-moon condition if the reset is not asserted at power-up). That issue is obvious looking at the ADC's Verilog, but only in hindsight. The issue now is, if you ever have a runt pulse on MCLK and a subsequent reset, it goes into an unrecoverable (without power cycle) state. Anyways, long rant, clocking the entire MCU from HSE during MCO turn-on seemed to fix this specific issue of a runt pulse.

[harerod]

Thank you for taking the time to update us. The MCP3914 will be added to the list of Microchip's analog devices (pun intended), that are to be used after careful testing, only.
Good look with the project, sounds like a pain in the neck.

On that notice: In the past Atmel has cost my customers and me lots of money, due to errata that we found. I was under the impression that after being bought, their new masters actually helped to improve overall, err, behavior. My most recent experience with Microchip support was bad, though. The bots who I had to deal with couldn't even understand simple English sentences.

[uer166]

I can complain how much of a POS this part is, but I cannot complain about Microchip's support: countless calls with the original designer of the IC (that they designed 10 years ago), acknowledgement of the issues, and looking into non-Microchip parts' datasheets to figure out what's going on.