Unexplained MCO behavior (?) on STM32F372CBT6

dandan9 · ‎2012-12-26

Posted on December 26, 2012 at 21:55

I'm running an external 26MHz xtal (10ppm) in HSE mode with the right multipliers/dividers to clock my STM32 core at 71.5MHz. Which works great. In addition, I have PA8 configured in MCO mode to drive said 26MHz clock out to a Bluetooth radio chip. There is definitely the expected frequency of square wave coming out. However, sometimes the radio link works and sometimes it does not. Here is what I've figured out.

If I run my mainline code full blast, talking over I2C, running the DMA engine into the USART Tx, etc. the radio link is unreliable.

However if I preempt my main while loop with a while(1); and just sit in one place looping on myself the radio works flawlessly.

Does anyone (Clive?!) know of any reason why the arbitrary execution of code could alter the quality of the MCO clock output? There is a lot going on on GPIOA in my design but nothing ever messes with that pin, of course.

(I did test the radio chip with a separately dedicated 26MHz xtal and turn off MCO - results were a rock solid radio link.)

Thank you all,

Dan

lowpowermcu · ‎2012-12-27

Posted on December 27, 2012 at 09:52

Hi Megadan,

What is the PA8 speed u r using? and what are the pins u r using in I2C and USART?

MCU Lüfter

dandan9 · ‎2012-12-27

Posted on December 27, 2012 at 19:17

Well of course I have PA8 configured as a 50MHz push-pull, alternate function with a pull-up. As I said, it will work to successfully clock the radio chip so the GPIO pin configuration is OK.

Other I/O pins in use on GPIOA are 17kHz timer driven PWMs on PA1-PA3, analog inputs on PA4-PA5, USART1 Tx/Rx on PA9-PA10 (112kb) and JTAG on PA13-PA14. The PWMs on PA1-PA3 are running in the background in both the working and non-working instances but there are no analog conversions running during the ''working'' instance of being in a while(1); since they are in one-shot mode. There is little to no data movement over the USART in either mode.

Thank you for your interest in helping me understand this!

Dan

Tesla DeLorean · ‎2012-12-27

Posted on December 27, 2012 at 19:49

I haven't spent much time with the F3, without seeing some code that illustrates the issue it's hard to tell if it's an initialization issue or an interplay issue with some other peripheral.

What frequency do you see at the MCO pin in the failing condition?

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

dandan9 · ‎2012-12-27

Posted on December 27, 2012 at 20:41

Hi Clive,

I do see 26 MHz on the MCO pin in both the working and non-working case. We used the extent of our 200 MHz Tek scope to characterize this signal but cannot detect or measure any difference (even in windowded FFT mode it really isn't the proper tool for frequency characterization of course).

Here is the code that sets up the MCO pin, pretty standard:

// This clocks the Bluetooth HCI chipset at 26MHz from our xtal

GPIO_InitStructure.GPIO_Pin = GPIO_Pin_8;

GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;

GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF;

GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;

GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_UP;

GPIO_Init(GPIOA, &GPIO_InitStructure);

GPIO_PinAFConfig(GPIOA, GPIO_PinSource8, GPIO_AF_0);

/

HSE clock selected to output on MCO pin(PA8)

RCC_MCOConfig(RCC_MCOSource_HSE);

//while(1)

; // uncomment to make radio work

while(1)

{

// Main operational code here

}

;

Thank you,

Dan