topic Re: about Errata 7293 in Vybrid Processors

about Errata 7293

alfred_liu — Tue, 11 Feb 2014 03:16:40 GMT

Hi, Vybrid expert

in Vybrid_1N02G, we descript 7293 as follows:

e7293: XTAL: ROM code may fail to boot and return to safe mode due to insufficient

warm up time for the crystal oscillator

Errata type: Errata

Description: On occasion the xtal oscillator may not get sufficient time to stabilize. In this case, the boot

code will jump to safe mode and will continue to operate from the internal RC clock.

Workaround: Use an external clock/oscillator module to clock to the processor, ensuring the clock signal is

stable no more than 1.2 msecs after reset is released.

so my question is:

can I understand this errata that customer MUST add a external clock/oscillator if they want to be safe ( I think it's a normal requirment)?

Re: about Errata 7293

naoumgitnik — Tue, 11 Feb 2014 22:18:46 GMT

Dear Weisong,

The Vybrid revision currently on the market has this issue fixed (the Errata document is a bit lagging, sorry...), so feel free to not read beyond this point :smileyhappy:

If you interested in the problem history and/or need a really precise clock, please, take a look at the below threads:

- https://community.freescale.com/message/351803#351803

- https://community.freescale.com/message/342197#342197

Regards, Naoum Gitnik.

Re: about Errata 7293

johnfielden — Wed, 12 Feb 2014 00:55:58 GMT

Hi, we just received production level V1.3 parts. We are still having problems reliably booting the Vybrid at cold temps (-20C is our products spec).

Looking at the crystal, we see that 3.2ms after 3.3V is applied, the Vybrid starts to drive the crystal. It takes about 800 us beyond that for the crystal to begin oscillating. This is true for room temp, or cold cases. We are only having the boot issue at cold.

We are booting from QSPI. When there is a boot failure, there is no indication that the Vybrid attempted to access the QSPI, so perhaps it is in safe mode.

How can we tell if the Vybrid is in safe mode? Is there an external flag of some kind?

Re: about Errata 7293

naoumgitnik — Wed, 12 Feb 2014 01:06:40 GMT

Hello John,

Are you sure this is the latest Vybrid revision?

What is written on the component top, please? - Either copy it or send a photo, please.

(BTW, if it is the same revision as the Errata document on our site, it is still the previous one - with the Errata document we are still one revision behind (sorry...).)

Yes, there is a bit indicating where Vybrid is booting from (please, refer to the Reference Manual for details).

Regards, Naoum Gitnik.

Re: about Errata 7293

johnfielden — Wed, 12 Feb 2014 18:11:56 GMT

We were just given 5 new production level parts by the FAE. They are supposed to be the latest silicon with the Vbat current problem fixed. We were told by the FAE that the version number portion of the part number on top would be no different than what we had before, but that these are updated silicon.

The part number on top is MVF61NS151CMK50. The other two lines on the part say, 2N02G and PTXCTAA1349N if that helps.

To differentiate the Vybrid's we have, we read the cpu version register using code provided with the Tower.

The CPU version register = 0x00000080

n = snprintf(p, n, "%d.%d\r\n",(*(int *)0x00000080 & 0x000F0)>>4,(*(int *)0x00000080 & 0x0000F));

The result is version = 1.3

Apparently version 1.2 was not entirely successful.

Re: about Errata 7293

johnfielden — Wed, 12 Feb 2014 18:15:33 GMT

We tried smaller load capacitor value on the crystal. No difference with 3.9pF or 6.8pF. About half the time it won't boot.

Re: about Errata 7293

naoumgitnik — Wed, 12 Feb 2014 18:33:35 GMT

Hello John,

Thanks for important information!

Yes, 2N02G looks like the latest revision.

Let me check this issue for you with the other teams.

Regards, Naoum Gitnik.

Re: about Errata 7293

johnfielden — Thu, 13 Feb 2014 00:53:44 GMT

We did an experiment where we removed the crystal and added a coax connector to a function generator. The generator is driving a 1.1Vpp clock out with a resistor divider setting the DC point at 0.5V (the DC point is divided from the Vybrid's 3.3V).

This means that we are driving the clock input even before the Vybrid is powered, but we are desperate at this point. At any rate, we've had no failures to boot at cold with this setup.

The giant hundred thousand dollar function generator will negatively impact our form factor. I would like to find an on-board solution. Looking at available oscillators, they all seem to require more than 1 ms to start up.

What is the timing specification for Vybrid power application to oscillator stable for this latest version of the part?

We have looked extensively at the Vybrid's 3.3V and the original crystal oscillator on an o-scope. No matter the temperature, the Vybrid doesn't apply an output to the crystal until 3.2ms after power is applied. The crystal starts oscillating about 0.8 ms after that. I am confused by the 1.2 ms or 1.4ms oscillation spec. Is the spec based on power application to the Vybrid, or, is it measured from when the Vybrid turns on the crystal. If the spec is based on the Vybrid's 3.3V, then the part fails to even power the crystal until long after the 1.4ms has expired.

If the spec is measured from when the Vybrid powers the crystal, then we are well within even the 1.2ms spec. If we are meeting spec, why does it fail cold?

Re: about Errata 7293

naoumgitnik — Thu, 13 Feb 2014 01:14:43 GMT

Dear John,

Thanks for the details provided, I will share them with my colleague currently investigating this issue. IMO, it will take several days.

A bit about timing...

Since the crystal oscillator is halted with Vybrid Power-On-Reset asserted, the time count starts when it is de-asserted. At the same time (and in our favor), power to the components, including an external 24MHz oscillator (if used), is applied without Vybrid Power-On-Reset delay, so you may easily provide enough time for the external oscillator to start-up.

A bit about external 24MHz oscillator type and connections...

Please, review Re: Workaround for unreliable boot from SD? to find a solution "ready for consumption"!

Regards, Naoum Gitnik.

Re: about Errata 7293

alfred_liu — Thu, 13 Feb 2014 06:15:13 GMT

Hi, John

Does your board have 2.2M ohm resistor on XTAL?

Re: about Errata 7293

alfred_liu — Thu, 13 Feb 2014 07:54:41 GMT

Hi, Naoum

Many thanks for your reply.

hopefully get the final result soon. :smileyhappy:

Re: about Errata 7293

naoumgitnik — Thu, 13 Feb 2014 18:24:18 GMT

Very good point, Weisong! This 2.2M resistor is indeed added to shorten the crystal start-up process (see "Errata" for details).

Thanks!

John,

Perhaps it makes sense to post the relevant schematic fragment with the oscillator circuit and the scope screenshots to illustrate the crystal oscillator behavior on your board, please?

(IMO, it is not the stray capacitance added to the limp load capacitors - lowering them down to 3.9pF does not help, as per your tests.)

BTW, how critical is the crystal start-up duration for you? Do you need it to be really fast?

The point here is that, as far as I remember, with the default setting of what is called something like "crystal wait time", which is 4ms, it should work. At the same time, there should be an option for the latest Vybrid to extend it up to 8ms.

jiri-b36968 kindly agreed to help with this issue - thanks in advance for that!

Sincerely yours, Naoum Gitnik.

Re: about Errata 7293

johnfielden — Thu, 13 Feb 2014 21:57:20 GMT

See the attached image for the schematic. The 2.2M resistor is in the circuit. If I grab a scope shot of the behavior, what do you want to see? 3.3V, Reset, and the Xstal?

Re: about Errata 7293

johnfielden — Thu, 13 Feb 2014 21:58:02 GMT

Note: R126 is not installed.

Re: about Errata 7293

naoumgitnik — Thu, 13 Feb 2014 22:58:30 GMT

Yes, John - mandatory Pwr-On-Reset and Xtal Output on the same screen, 3.3V being "nice-to-have", and if possible for both passing and failing cases (with temperatures mentioned, I guess...).
Still no reply regarding lengthening "crystal wait time" if possible for your application...

/Naoum.

Re: about Errata 7293

jiri-b36968 — Fri, 14 Feb 2014 09:21:28 GMT

Hi John,

you mentioned label 2N02G which indicates revision of Vybrid rev 1.2 (latest). This Vybrid revision does not have issue e7293. It was issue only on 1N02G (rev. 1.1)
XTAL is enabled about 4ms ofter POR. Then there is the delay which waits to XTAL start oscillating. Check is done using internal timer driven by XTAL. Default delay time is 4ms controlled by SIRC. This time can be changed by OSC_TUNED fuse from 0 up to 8ms.
Important time is not starting of oscillations but time when you have stable oscillations with minimal amplitude 0.5V pp. Usually 0.8V pp. This have to occur between XTAL enable and 4ms deadline.
Please confirm: Booting of your modules are 100% OK on normal temperature, but 100% fail on -40°C ? At which temperature it starts failing?
Please confirm at -40°C with external clock source your modules are 100% OK.
Possible reasons:
- wrong oscillator bias in low temperatures. 2M2 resistor is important for setting correct bias of oscillator. Please check if bias is correctly set. You can send oscilloscope waveforms with /RESET, XTAL, EXTAL and BCTL for room temperature and for -40°C. Please note that oscilloscope probes add parasitic capacity (usually about 10pF on passive probes).
- wrong OSC_TUNED value. Please confirm that you have not changed the value of the OSC_TUNED FUSE.
- wrong calibration of SIRC oscillator which defines 4ms delay. You can change t by program OSC_TUNED FUSE to 8ms delay. Fuse is located in Bank0 Word7 Field[31:24]. If you do not know how to program it, I can guide you.

/Jiri

Re: about Errata 7293

johnfielden — Wed, 19 Feb 2014 18:26:21 GMT

The version register says 1.3. But we accept that we have a newer part than v1.1.

- We see 100% ok at room temperature.

- We see 50% failures at -20C. Our product spec doesn't go down to -40C.

From the scope, we see the Vybrid enable the crystal 3.2ms after the 3.3V rises to peak. The oscillator starts oscillating and appears to reach full amplitude about 0.8ms later. We didn't look at the reset line this time, but from past experience the reset is released about 600usec after 3.3V is at peak.

So, we're seeing POR to osciallator at full swing of around 3.4ms.

We have not blown any fuses on the Vybrid. Frankly, we are scared to do so. But, we will make an exception in this case.

We tore our test setup down and were pursuing using an oscillator instead. But, we will change course and try the fuse option first. We are behind schedule and can't take too much more time experimenting with the device.

Re: about Errata 7293

johnfielden — Thu, 20 Feb 2014 00:27:05 GMT

We've looked at the documentation are are confused.

Section 19.3.1 – Boot eFUSE Description (p 828)

OSC_TUNE D[7:0] – Bank Word7 Field 31:24

0x00 = OSC_TUNE will be filled with POR default (OSC_TUNE POR Value = 0x57)

Non-Zero = This will become the POR OSCNT value in bootrom

Section 19.4.3 – Clocks at Boot Time (p 832)

This section discusses how CCM_CCR[OSCNT] is used at boot time. It says the customer can over-ride the crystal startup time.

Wait Time = 1.5 * (CCM_CCR[OSCNT]/SIRC)

SIRC = 128 KHz

With OSCNT = 255 wait time would be 1.5 * (256 / 131072) = 2.93 ms

With OSCNT=Default (0x57=87) wait time would be 1.5 * (88/131072) = 1.01 ms

Section 10.2.1 CCM Control Register (CCM_CCR)

This section discuss how OSCNT is used and lists the POR value. Oscillator ready counter value. These bits define value of 32 KHz counter, that server as counter for oscillator lock time. This is used for oscillator lock time. Current estimation is ~2.7 ms. This counter will be used in ignition sequence and in wake from stop sequence if CCM_CLPCR[SBYOS] bit was defined, to notify that on-chip oscillator output is ready to use.

00000000 = count 1 cycle of 32 KHz SXOSC clock

11111111 = count 256 cycles of 32 KHz SXOSC clock

01010111 = POR = 0x57

0xFF – 0x57 = 0xA8 (168)

Calculating time to add the additional time to the started 3 ms… 168 / 32768 = 5.12 ms --- So that gives us ~8 ms!

If it is the OSC_TUNE D that needs to be burned, what value gives us 8ms?

What about the other fuses associated with the oscillator? Do they need to be blown too?

Re: about Errata 7293

alfred_liu — Thu, 20 Feb 2014 08:30:10 GMT

Hi, Jiri

Any concolusion for this issue?

Re: Re: about Errata 7293

jiri-b36968 — Thu, 20 Feb 2014 09:32:33 GMT

Hi John,

on rev 1.2 default wait time was increased to 4ms.

Delay time is clocked by SIRC. 1/32000 * 256 = 8ms counting SIRC (128kHz /4). Maximal wait time for XTAL is 8ms (SCNT = 255).

Deadline is counted by PIT counting IRC (24MHz) with deadline time 1.5 * delay time.

Please program just OSC_TUNED Bank 0, Word7, byte 3 to 0xFF.

Programming project is part of Vybrid sample code freescale.com/vybrid ( http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=TWR-VF65GS10&fpsp=1&tab=Design_Tools_Tab#)

Modify \src\projects\ocotp_fuses\ocotp_fuses.c in ocotp_fuses project. (my In attachment).

Final binary ...\build\ds5\projects\ocotp_fuses\Debug\ocotp_fuses.axf (my binary is in attachment also)

/Jiri