MCF5329 oscillator do not work

[maxhexis]

Hi all,

I have a problem with a brand new MCF5329 board. I have decidedd to use the internal XTAL oscillator, so I just attached the classical 1 MOhm feedback resistor between XTAL and EXTAL, in parallel to the 16 MHz crystal, and two 15pF capacitors toward ground.

Then I just apply power, keeping the external reset active, and I notice that the oscillator do not work.

The strange thing is that I find 3.3 Volt on both XTAL and EXTAL, while I expect to find opposite polarities, as there is an inverter between the two pins inside tthe CPU.

I have also checked power sequencing, and it works fine, rhaving 3.3 V rising in about 1 ms, followed by 1.5V supply.

Of course the BDM is not working, too.

I have also analyzed system behaviour at poweroff, and I noticed a brief oscillation of the crystal when the power is ramping down.

Any suggestion?

[TomE]

> suggestions

1 - Compare with a known working board. See what the XTAL and EXTAL pins do on it.

2 - Look for shorts to those pins. Measure their resistances (compare good and bad boards).

3 - Remove the 1M resistor. Try another crystal.

4 - Which way do you have RCON pulled?

5 - Check VDD, EVDD, IVDD, PLL_VDD.

6 - Is this a newly designed and loaded board? Check that nobody missed out connecting one of the undocumented power and ground pins:

Pin  V   RM&DS   EVB          PosRef & Validation Board=======================================================M12: 1.5 IVDD    CORE/VDD_D   CORE/VDD_DM11: 1.5 IVDD    VDD_RTC      VDD_RTCJ12: 1.5 PLL_VDD VDD_A_PLL    VDD_A_PLLM6:  2.5 SD_VDD  SD_CLK_VDDE  SD_CLK_VDDEM9:  3.3 EVDD    TCLK_VDDE    TCLK_VDDEK12: 3.3 EVDD    VDD_OSC      VDD_OSCL12  0.0 VSS     VSS_OSC      VSS_OSCL13  0.0 VSS     VSS_USB      VSSK13  0.0 PLL_VSS PLL_VSS      PLL_VSSM14  VSS USB_VSS USBH_VSS     USBH_VSS

[maxhexis]

Thank you for you fast answer.

In the following my answers to your suggestions:

1) In a working board these two pins just start to oscillate right after power-up. Unfortunately, I do not have an MCF5329 board, but only similar ones (MCF52211, MCF51JM). Oscillator scheme is exactly the same, and I never had this problem in my past designs.

2) No short is present on these pins. In fact, furing the power off sequence, the oscillator starts for a short time before turn off. It seems like the MCU read a bad configuration which disabled oscillator pins. Of course, I cannot check this, as BDM is not working without a clockh signal.

3) I have already tried with and without the feeedback resistor, as in two different Freescale designs the resistance is or is not present. I will try to change the crystal, but it works well on similar designs. Usually crystal incompatiilities can give problems of slow start or instability, especially at a frequency as moderate as 16 MHz.

4) The RCON pin is pulled low with a short to ground, as I have an external reset circuitry which set D9-87-1 accordingly to the manual. I have also checked voltage levels on the bus keeping the MCU in reset, and they are right. Is it a problem to have a direct connection from RCON to ground, instead of a pulldown resistor?

5) I double checked the layout of the PCB, and it seems ok, but, of course, as I use a BGA 256 package, I cannot be sure of solder joint quality, even if the manufacturer has long experience on BGA devices. I'm currently waiting for an empty PCB from the manufacturer to check for possbile Gerber errors.

6) The board is newly designed, but power topology is directly taken from the Freescale reference design, in which undocumented power pins are connected with eventual filtering. The only difference is that I use 3.3V SDRAM, so SD_VDD is connected to EVDD, but this is not a concern for the crystal oscillator. PCB traces of the oscillator are carefully layed out, too, having about 1 cm length, without vias, and with a full ground plane under the oscillator.

Any other suggestions?

Thank you in advance

[TomE]

We have RCON set to its default state and it works OK for us. I don't know of any problems with it or with your setup. We're using VDD connected to EVDD as well.

Can you try ramping the power supplies up v_e_r_y__s_l_o_w_l_y? Like in the order of tens of milliseconds?

We've had to use a slow ramp to stop the SDRAM controller's random startup from crashing the CPU, but with slow ramps you can see when (on the ramp) different events inside the chip happen - when the oscillator gets enabled, when the SDRAM pins un-tri-state, when the SDCLK output starts running and so on.

Other suggestions - pullups and pulldowns on the XTAL and EXTAL pins in case you can force them to their active regios.

Next though, I'd suggest driving an external 16MHz (through a resistor) into whichever of XTAL and ExTAL is the input - that would be EXTAL. See if you can force it to start like that. That might get the BDM up at least.

Check the /RESET input signals and /RSTOUT for any activity. Also the SDRAM pins from going from tri-state to driven, and the SDCLK signal which should follow the crystal when it is running.

[maxhexis]

Thank you again for your answers.

I cannot use defaults for RCON, as boot flash is 16 bit only, and I do not use DDR SDRAM, so split bus is not recommended by Freescale for this situation. Datasheets describe only 32 bit SDR interfacing or 16 bit DDR, even if in the forum I have found some evidence of 16 bits SDRAM systems working.

I will try, as you suggest, slow ramps on vdd, but I wonder the SDRAM controller is not correctly initialized at reset. If true, it must be declared somewhere, even in design errata (I hope), as it hurt data bus behaviour, i.e., configuration, at reset.

Next I try an external oscillator, too.

I will post here experimental results as soon as possible.

Thank you in advance,

[maxhexis]

Hello!

I have definitely identified and solved the problem.

It derives from a conflict between external memories and the buffers used to load configuration inside the MCF5329.

The point is that some settings, like the oscillator ones, are continuously sampled by the processor while the reset out pin is active.

In the meanwihile, I/O pins, including bus control signals are in high impedance, and do not actively drive external memories. If the chip select pins of the memories are at a 0 value (active), then the data bus is driven by the memories itself, thus overriding the desired values.

It's particular the fact that no internal pull-iups are used on theese critical signals.

The exact value reached by floating pins during power up is related to power supply rise time, and to PCB layout (due to capacitive coupling effects).

In my specific board, power up led to activation of chip select signals, thus loading a startup configuration which disabled the crystal oscillator.

The remedy is quite simple: I just put two pull-up resistors on both FLASH and SDRAM chip selects, in such a way to guarantee they are disabled for all the time the reset output is low.

In the reference design from Freescale, the used configuration is the default one (no RCON activation).

If anybody have a demo board, it could be interesting to monitor memory chip selects at powerup.

Anyway, now my board is working fine, so I hope my experience could be of help to other designers.

Thanks again for the suggestions

[TomE]

> In the reference design from Freescale, the used configuration is the default one (no RCON activation).

There are at least THREE Freescale Reference designs for this chip. One even uses 16 bit FLASH, RCON and has a pullup on the FLASH chip select, just like you now do. Search for "POSREFDESIGNSCH" on Freescale's site, that finds the link. Also look for "MCF5329_REF_DES" for another one (16 bit FLASH, no pullup, needs one), and the MCF5329 EVB Evaluation Board (32 bit, can't see a pullup).

All chip-select pins (that connect to peripherals) must have pullups to avoid this and other problems.

[TomE]

> will try, as you suggest, slow ramps on vdd, but I wonder the SDRAM

> controller is not correctly initialized at reset. If true, it must be declared

> somewhere, even in design errata (I hope), as it hurt data bus

> behavior, i.e., configuration, at reset.

"Should" be declared in Errata, but isn't. I've asked for this to be documented, but suspect the priority of this work depends on who is affected.

You may have discovered another side effect of this problem with this chip.

It may be that it can't be used reliably with RCON asserted and with external SDRAM.

The SDRAM controller IS NOT asynchronously initialised by the RESET signal. It initialises in a "random state", and requires the crystal to start running and providing clocks so it can synchronously clock itself back to the reset/idle state. Sometimes these initial signals cause the SDRAM to drive the bus. Most often on power-off-wait-2-seconds-power-on.

I spent a few months fighting this problem with good help from Freescale through our distributor. Documented here:

https://community.freescale.com/thread/69745

Combine that power-on-random state causing the SDRAM to drive the data bus, add to that your "Data pins driven with RCON asserted disables the crystal" and now it can't clock itself out of that state.

To get around this you need your power supply design to get the crystal running BEFORE the SDRAM signals come out of tri-state.

The Crystal isn't guaranteed to work with VDD below 3.0V, but it seems to start with VDD at 1.6V and IVDD at 0.6V.

The SDRAM pins are enabled when EVDD is at 2.6V (min 2.0, max 2.8).

I suggest you change your power supplies to guarantee the crystal is running prior to SDRAM pin enable. We're using a 30ms VDD ramp and a 1.0V low-drop regulator from VDD supplying IVDD. This requires a ramp-controlled switching regulator for VDD.

Adding PULLDOWNS to SD_CLK and SD_CKE seems to minimise this problem too.

I would suggest you power cycle your design at least 1000 times with varying power-off times in case you get this SDRAM controller lockup. It depends on the brand of the SDRAM too.

> I just put two pull-up resistors on both FLASH and SDRAM chip selects

The SDRAM one does nothing. SDRAM chips don't work like that. There is actually no guarantee from any SDRAM manufacturer that the data pins will be tri-state until the full multi-command initialisation sequence has been run. Reading the boot code from a FLASH on the same data bus is "technically outside of SDRAM specifications". One manufacturer's data sheet states:

-     Note 4. Outputs are guaranteed High-Z after the command is issued.

Another data sheet states:

  FUNCTIONAL DESCRIPTION
    Initialization
          Outputs are guaranteed High-Z after the LMR command
          is issued. Outputs should be High-Z already before
          the LMR command is issued.

"Should" but not "Guaranteed". The only guaranteed setup is the split bus one.

[maxhexis]

I understand the problem. Luckily, my design already has needed features to implement the workarounds you suggested:

1) I have a quite sophisticated power sequencing scheme, in which I can easily decide power supply ramp up speed. So I'll apply a 30 ms power-up time to 3.3V. Then I will ramp-up 1.5V with the same speed. I have an LDO regulator enabled by the power good signal of the 3.3V dc/dc

2) I have an external reset controller, capable to keep reset asserted for about 200 ms after power-up. This could give enough time to the SDRAM controller to initialize correctly, as the crystal oscillator can freely start well before the boot sequence.

3) I have measured the impedance of SDRAM chip selects during reset, and they seems to be in high impedance. Pulling them up, disables the sampling of other control signals, allowing the SDRAM controller to reset without having the risk to trigger other SDRAM operations. Besides, having CS high with the clock running helps to initialize internal SDRAM circuitry correctly. Of course up to now I just have a single brand of SDRAM on my prototype board.

4) Last, I will use bleeder resistors on power supply, in the range of some kOhm, as I do not have strict requirements on power consumption. This, joint to the value of filter capacitors used, will lead to a time constant of about 0.1 s during poweroff. It means that, if I can wait just 1 second in the ON-OFF-ON sequence, I can  have probably SDRAM completely turned off.

I will test these workarounds on Friday, and will let you know the results.

Best regards

[TomE]

> 1) I have a quite sophisticated power sequencing scheme, in which I can easily

> decide power supply ramp up speed. So I'll apply a 30 ms power-up time to 3.3V.

> Then I will ramp-up 1.5V with the same speed.

That won't work.

The critical thing is to get the oscillator running BEFORE the pins come out of tri-state.

It took weeks to get the details of what voltages feed into the "tri-state control".

Here's the incomplete table:

SDVDD  IVDD     Vtrip Max  Vtrip Min   Hysteresis3.6    Rising   .980       .785        .1403.6    Falling  .723       .552        .1401.6    Rising   .695       .530        .1591.6    Falling  .373       .117        .159Rising 0.0      .450       .115        N/A

So the trip point depends on SDVDD and IVDD and the "trip point" for one of the rails changes depending on the other rail.

But the above table is incomplete as there is another monitor in the chip on EVDD that trips somewhere between 2.0V and 2.8V, with a typical measured 2.5V on our chips.

The pins come up "three way random", meaning either output high, output low or INPUT (yes, the outputs can come up as inputs) with tri-state overrides from the SDVDD, IVDD and EVDD as above. Here's a direct quote from Freescale:

In order to prevent possible unknown states on the pads, the goal is to have IVDD at least at minimum operating voltage and the oscillator toggling before EVDD reaches 2.0V. If you do that the digital logic will be initialized before the pads are enabled.

In order for the oscillator to start, IVDD has to be at least at 0.7V and VDD at least 1.7 (although Freescale won't guarantee the oscillator below 3.0V). Very strangely, IVDD has to be at that level for the oscillator to START, but it will keep going with IVDD at zero during a brownout. Weird logic. I shouldn't have to know this!

If you need a guarantee:

> So you can actually start up the crystal if you power OSC_VDD and IVDD.> So a second option is to have two 3.3V rails--one for OSC_VDD and a> separate supply for EVDD. That way you can get the oscillator> running before EVDD reaches the 2.0V threshold.

"OSC_VDD" is one of the undocumented power pins. You can find it in any of the three reference schematics, but not in the Reference Manual or Data Sheet.

So you want a slow ramp on 3.3V and the 1.5V LDO regulator permanently enabled so it follows the 3.3V ramp. IVDD has to get to a working level before the 3.3V gets to 2.0V or the oscillator won't be going. If you take a worst-case 10ms oscillator start, then you need 10ms between your 3.3V being at 1.7V (osc start) and 2.0V (pin un-tri-state).

> I have measured the impedance of SDRAM chip selects during reset, and they seems to be in high impedance.

As soon as EVDD crosses about 2.5V the outputs are enabled. Some chips wake up driving this pin high (disabled) but different chips can wake up the opposite way. The SDRAM chip ignores "chip select" until initialised properly, half way through your boot. It takes far more notice of the floating SD_CKE and SD_CLK signals during the ramp-up, and these are the ones that set the stage for the "random" outputs of the controller to then lock it up. Having the chip select high won't stop this. Pulldowns on SD_CLK and SD_CKE seem to help. I have about 100 CRO traces on file of this sort of thing.

> 2) I have an external reset controller, capable to keep reset asserted

> for about 200 ms after power-up. This could give enough time to the

> SDRAM controller to initialize correctly, as the crystal oscillator can

> freely start well before the boot sequence.

You need the crystal running to reset the chip internals before it enables its output pins. The "random pin states" can make the SDRAM drive the data bus. In your case that could turn the crystal off and you'll never get a clock and never get out of that state. If the FLASH chip-selects wake up "random" too (I've never checked this as we're not using RCON) then they could stop your clock too. It doesn't matter how long the reset is, if the crystal isn't running you're stuck.

> Last, I will use bleeder resistors on power supply, ... I can  have probably SDRAM completely turned off.

We did the same, but "completely turned off" is no guarantee. The SDRAM Controller can still be random, even from a cold power-up and the SDRAM can then still wedge.

> Of course up to now I just have a single brand of SDRAM on my prototype board.

Check your private messages.

[maxhexis]

This week I have extensively tested my board paying attention to your considerations. I have carefully examined SDRAM control signals during startup. Please notice that I have added pull-up's to 3.1V on them, too, to be sure to detect when they are driven or not.

The key point is that I never detected a random behaviour. It is really deterministic! It is the following:

1) When power is applied, first control signals are high impedance, i.e., I have a logic'1' due to pull-up's

2) Just before the first transition of the SDRAM clock, I have control signals going to '0', and than to '1'

I'm able to see a different situation only if I turn power off and then on very rapidly. In this case, I do not see the glitch at all. This is probably due to the fact SDRAM controller do not miss the previous state.

Of course, I'd prefer to see control signals held at '1' during power transitions, but this situation do not seem to create bus contention problems, as no clock edge is sent to the SDRAM while controls are active.

Which is the mask set of your CPU? Mine is 4M29B, datecode 1023. Please, look at your personal mail.

[TomE]

> Please notice that I have added pull-up's to 3.1V on them, too, to be sure to detect when they are driven or not.

Don't leave pullups on SD_CLK or SD_CKE. On our board that makes things a LOT worse. Add pullDOWNS for your production. I added "pull to 1.6V" resistors for telling tri-state from drive-high and drive-low.

> I never detected a random behaviour. It is really deterministic!

Are you monitoring all the SDRAM control signals? I had to use a logic analyser to get enough channels to see what was going on. You should also be monitoring at least one data bus line with a "pull-middle" on it. That's the only way to know if the SDRAM is misbehaving. MOST time when this happens the SDRAM chip lets go of the bus after the SDRAM controller comes good, but sometimes it doesn't.

> Just before the first transition of the SDRAM clock, I have control signals going to '0', and than to '1'

That's the transition that can cause the SDRAM to enable its outputs and jam the bus.

What the hardware should be designed to do is:

1 - Power on, power ramping up,

2 - SDRAM controller outputs all tri-state. You need pull resistors to control them in this state.

3 - SDRAM controller outputs initialise in "IDLE" state (usually high).

4 - SDRAM Controller outputs enabled (come out of tri-state), now driving "IDLE".

5 - They STAY THAT WAY until your bootstrap initialises the controller.

What the hardware really does is at (3) the randomly initialised flip-flops in the SDRAM controller drive the pins into non-IDLE states.

If you can get the oscillator running before the pins un-tri-state then it all works OK. That's the best solution. It is also easy to achieve this with a slow enough VDD/EVDD/SDVDD ramp and the IVDD being active during this time.

> I'm able to see a different situation only if I turn power off and then

> on very rapidly. In this case, I do not see the glitch at all. This is

> probably due to the fact SDRAM controller do not miss the previous state.

That is due to the oscillator not stopping during that test. The oscillator is still running  and is clocking the SDRAM controller before it un-tri-states. Look at XTAL with a CRO during these tests.

> but this situation do not seem to create bus contention problems

it did on some of our boards. How many boards have you tested?

> Which is the mask set of your CPU? Mine is 4M29B, datecode 1023.

Same mask. I don't expect the datecode to matter.

Concerning using an external oscillator, I think you can get the same confidence by using a slow ramp that guarantees the crystal is running (monitor XTAL).

Check your private email again.

[maxhexis]

I can confirm I have carefully monitored every control signal with a multi-channel digital oscilloscope, and I never detected the weird behaviour you have described, but I have just tested one single prototype.

Anyway. I redesigned the board with:an extenral XCO with fast startup time (10ms max).

Moreover, I thought I will configure the chip at boot-up with PLL bypass, to be sure to propagate a good clock to the SDRAM controller without any delay (PLL is powered by IVDD power). The firmware will start the PLL in  the initial boot sequence, before initializing the SDRAM.

I have also delayed the powerup ramp to have roughly 100ms turn on time.

I think I will have a new prototype at the end of November, after that I will write here my test results.

[maxhexis]

Hi,

I had some delay to receive the new board with the required modifications. But good news are here! It works, exactly as supposed. The trick is to use an external XCO, supplied by 3.3V, and delay a while the 1.5V core supply. This way, I hava no more glitches on both SDRAM and FLEXBUS control signals.

I have alreary ported U-boot to the new platform, and it works seamless.

Thanks again for the previous discussion and useful suggestions.

[maxhexis]

Well, after a wihle, I thought I want to have 100% guarantee of a working system, so I thinlk I will use an external oscillator, and I will power the CPU only when the oscillator is stable. Of course, this imply using an additional buffer and some added EMC problem, but for me it is preferrable to have to replace boards on the field.

By the way, I have read on the datasheet that SDRAM controller has a minimum working frequency, so I think the problem o wrong initialization is due to the presence of some dynamic logic inside the chip.