S12XF on EVB9S12XF512E Flexray PLL doesn't lock

[qty154]

Hello all,

Once a provided demo app. suddenly ceased to work. I debugged it and it seems that the internal CGM PLL that provides clock for the FR module doesn't lock.

I wrote a small program that tested all the possible combination of SYNR and REFDIV values, but the PLL never locks.

The rest of the chip seems to work.

??? What happened ???

As a workaround I will try to put a 80 MHz quartz oscillator instead of the 4 MHz crystal on the board. That should clock the FR module according to the manual. But, will it work as a clock to the rest of the MCU? I can of course use the (other) PLL to even divide the clock frequency as well, but I mean, 80 MHz isn't to much for the EXTAL input?

Another question on side is a that some components are mounted on the EVB around a pin called XFC. This pin of the MCU is not even named in the ref. manual.  It is marked as NC (not connected) What is it and what are those components for?

Best regards

Attila

[DPB]

Hello

The maximum oscillator pin frequency is 40MHz in the full swing Pierce oscillator configuration (RM Table A-21).

NOTE: The configuration can be selected using the XCLKS signal (PE7).

The oscillator input does not function reliably at 80MHz.

The XFC reference on the EVB is inherited from  EVBs for other S12 devices that used an XFC pin.

These older devices used XFC to connect an external loop filter for the PLL.

This is no longer required for the S12XF device, which features an internal filter.

Which CGM PLL settings are you using ?

If your small program periodically reconfigures SYNR and REFDIV, do you allow sufficient time for stabilization before changing the SYNR and REFDIV values?

DPB

[qty154]

Hi,

I am using the attached standalone_LS program that came along with the EVB, with its original  settings. The same program works fine on the other node.

I also tried to sweep across all the possible combination of the divisor values, I let the PLL lock in a while(x++< 0x1000); loop, but the PLL never locked.

I donno what happened, I got the EVB already failed. I will investigate what caused it to fail, but anyway, it is very weird that an internal PLL doesn't work any more.

By the way, what are you saying of maximal oscillator frequency? The processor RM says this about the Flexray clock:

13.4.1 Oscillator Clocking
If the protocol engine is clocked by the internal crystal oscillator, an 80 MHz crystal or 80 MHz CMOS
compatible clock must be connected to the oscillator pins. The crystal or clock must fulfill the
requirements given by the FlexRay Communications System Protocol Specification, Version 2.1 Rev A.

Do you mean that an 80 MHz oscillator is out of specification? What??

Best regards

Attila

[DPB]

Hello

What voltages do you see at VDDPLL, VSSPLL? 

Does the other PLL in the S12XCRG lock?

The RM 13.4.1 is misleading. The Flexray specification is a general one because the Flexray module is integrated on other device families, where an 80MHz crystal can be connected. For the S12XF-Family the maximum oscillator frequency is 40MHz, thus the PLL is required to attain 80MHz. 

I shall get the RM updated.

DPB

[qty154]

Hi DPB,

To answer your question:

VSSPLL = 0V (grounded on the EVB)

VDDPLL = 1.8V

Yes, the normal clock PLL locks.

Just have a look at the (otherwise unserious) RM, fig. 2-15 and fig 2-16, where exactly is the FR clock taken from when CLKSEL bit in the FR MCR register is set to 0?

//Attila

[DPB]

Hi Attila

With CLKSEL=0 the FR clock is taken from the oscillator, equivalent ot OSCCLK in fig 2-15, 2-16 (max 40MHz)

However referring to the NOTES in section 1.2.1, this is intended for test purposes.

For applications the PLL should be used.

The fact that the system PLL is locking, indicates that the oscillator is operating properly.

In your second post above, you mention that  "The same program works fine on the other node".

Does this mean that the Flexray PLL locks on one S12XF device but not on another? If so perhaps there is a device defect.

Can you confirm that CGMTEST0,1,2 all read back 0x00 ?

Does LOCKIF ever get set, indicating a temporary lock status followed by a loss of lock?

Did you try other crystals in the 2MHz to 40MHz range?

Regards

DPB

[qty154]

Hi DPB,

Yes, you are correct, the other node is completely OK, while this node doesn't work which means that the failure probably lies inside the MCU.

I tried different 4MHz crystals - same result - but not different ones. Or right to say, I tried it with this 80MHz oscillator, but the PLL doesn't lock.

Yes, CGMTESTi = 0 all the time.

No, the LOCKIF doesn't get set, not even for momentarily. So there is no loss of lock, there is no lock at all. The UNLOCKF flag is always 0.

Anyway, I tried this 80 MHz oscillator that I bought yesterday, and it seems that the MCU works. I will try if the FR works also tomorrow.

By the way, the ECRG.POSTDIV register is missing from all the attached demo codes. Simply there is no such define in the S12XECRG.H file.

By the way, it is a little bit weird that the RM says that the CGM PLL should be programmed to 80MHz while in the low speed examples, it is set to 10 MHz only. I think the RM is quite ridiculous. Ok, unreliable, better said. Either FR works with several other clocks (probable since FR standard allows lower baudrates), or, the programmer of the demos, Jaime Orozco, is too creative. Not talking about PLL VCO frequency range...

Not even talking about the MCU product brief document, which is still preliminary. Since 2006 ....

//Attila

[DPB · Accepted solution]

Hi Attila

If one device FR PLL works and another doesn't with exactly the same configuration and the oscillator input is proven to work on the bad device by the fact that the other (system) PLL locks OK, then it really does sound like a defect.

Note that an external 80MHz oscillator is not guaranteed to work over the whole specified temperature range.

The maximum input frequency from an external oscillator is 50MHz (RM Table A-21).

Which demo code and development tools are you are using? In the above thread there is apparently no reference.

Perhaps the demo code is intended to support other device families that allow a lower frequency FR clock input.

The Flexray specification in chapter 13 of the RM is a general specification used for different device families.

The RM uses section 1.12 to describe S12XF specific clock considerations and constraints.

The incorrect reference to 80MHz crystal in chapter 13 has been fixed. The updated RM shall be published soon.

Regards

DPB

[qty154]

Hi DPB,

I'm currently using the standalone_LS demo that I downloaded from here:

www.freescale.com/webapp/sps/site/prod_summary.jsp?code=EVB9S12XF512E&fpsp=1&tab=Design_Tools_Tab

I gonna have some experiments with the EVB9S12XF512E_Nodex_FS demos to see if the Flexray module works indeed with the 80 MHz oscillator.

Temperature is not a problem since I use this kit in the lab. Hopefully the MCU will survive my experiment.

I myself am very happy that you use a 'carry over' Flexray module from other products, but the document, MC9S12XF512 Reference Manual and Data Sheet, should be about just exactly the MC9S12XF512 MCU, nothing else. Moreover, the design to incorporate this FR module should be done in a way that it is seamlessly integrates to the rest of the MCU. In our case, the FR module can be clocked by the external crystal, however, the MCU is not supporting the necessary 80 MHz frequency to operate at 10Mbit/s, which is defined by the flexray standard. Then, what's the meaning of this possibility?

Maybe the issue is of little importance, but I can tell you, this MCU family hasn't become my favorite. I will not use this MCU for flexray.

Best regards

Attila