OMAP-L137 power up reset problem

Harri,

Section 6.3 Power Supplies in the OMAPL137 datasheet states that the recommended sequence is 1.2V-1.8V-3.3V, with no voltage ramp requirements.

Based on your problem description, it sounds like the device may not be catching the bootmode correctly.  There are a few things you can try to prove/disprove this:

1. Check the SYSCFG->BOOTCFG register.  This will show you what OMAPL137 saw on the BOOT pins during reset.  This value is only captured once during reset.
2. Can you read back the ROM boot revision ok on a bad powerup?  It should be D800K00x.
3. Are both TRSTz and RESETz pulled low during reset and powerup?  PORz is triggered by both RESETz and TRSTz
4. Do you have visibility into the RESETOUT signal?  This will tell you when PORz has completed.  The time for RESETz released -> RESETOUT should be the same between board power up and reset button.

-Tommy

Hi Tommy,

the problem is that I can't connect to the board with JTAG after a bad reset. So I can't confirm those things related to register content.

As for power sequencing, the app note at http://focus.ti.com/analog/docs/refdesignovw.tsp?familyId=64&contentType=2&genContentId=51802 shows the order RTC_CVDD--CVDD--PLL0_VDD--DVDD--USB_VDD. Then, in the end of the page there are some examples with different powering schemes, all of which have the order 1.2V-3.3V-1.8V implemented. This is the ambiguity which makes things a bit confusing. Including the datasheet to these two examples we have three different instructions for the sequence.

TRSTz is pulled low with a 4k7 resistor, RESETz works from TPS650532 (see above).

I've observed RESETOUT and it goes high even on a bad reset. I'll check the timing but is the time to RESETOUT high really as you say? I the datasheet, section 6.5.3, table 6-2 shows different delays on cold and warm reset.

I have 47k pulldowns in the BOOTMODE lines whereas the EVM has 20k, do you think my pulldown is too weak?

Harri,

I assume that you are performing a PORz when you use the reset switch so I would expect the powerup and switch-PORz to have the same RESETOUT time.

What bootmode are you using?  47k pulls may be too weak.  3.3V/47k gives you about 70uA, but the internal pulls can oppose with as much as 200uA for pullup and 300uA for pulldown. 

-Tommy

Ok, I haven't got the opportunity to check the RESETOUT timing because the boards are running a long reliability test.

I'm using SPI flash boot. I raised the 1.2V power slightly (now measures 1.25V close to OMAP) and noticed the wakeup improved. The downside was that my crystal has difficulties starting oscillation and didn't find the correct load cap setup yet. However, if I hold a scope probe on one end of the crystal, it starts up and the CPU powers up properly every time. I'll try the same on another board which has a different power domain and a more reliable crystal.

I'll also replace the pulldowns to be sure on that part.

Thanks a lot! I'll get back with further observations later.

     Harri

I replaced the crystal and the new one seems to start better. I just had to use very low (6.3 uF) load caps. Do you know why raising the 1.2V line affects the oscillator so much? When it hasn't started, looking with a scope it looks like it starts when the voltages bleed off after switching off the power supply. Is there something else to try, maybe a resistor in parallel or in series with the crystal?

By this experience, I still don't know if the problem is somewhere else and raising the voltage just happened to improve the situation a bit. I didn't get my hands on new resistor networks for the BOOTMODE pulldowns yet but it really looks like it isn't a problem. The board starts up every time the oscillator does.

Harri,

Glad you're making some progress.  The oscillator operates off of the 1.2V power supply so if the problem is rooted in too much load hanging off of the oscillator output, raising the 1.2V supply will indirectly increase the drive strength of the oscillator.

-Tommy

Okj, that makes sense, thanks for the clarification. I'm still a bit confused about the momentary startup during power bleed-off but nevermind.

What do you mean by too much load on the osc output? I'm asking because on my other board the oscillator starts up well with slightly lower 1.2V line voltage and same crystal with larger (10pF) load capacitors. Are you just referring to wrong load caps or some other problem?

The next step is to do the 1.25V mod to the other board and see if it shows the same difficulty with the osc. Or better, if it starts booting which was the initial problem.

Rgds,

     Harri

Harri,

By too much load, I'm speaking to the amount of voltage/current required by the crystal to ring.  Is the crystal circuit using the OSCVSS pin for isolated ground?

-Tommy

That's been one of my concerns during this project. I didn't spot the hw design instructions about OSCVSS and connected it to the system digital ground plane. I asked about it on this forum and someone said it shouldn't be a problem. Now that I'm facing this problem, I'm beginning to think it's the reason. Do you have any advice for improving the situation or is the only way to tweak the cap values and hope it works?

  Harri

Harri,

There's no way for me to know if your problem is really with the digital ground or not, but I was told that the dedicated OSCVSS pin was introduced on newer designs like this because older devices ran into oscillator problems when there was noise on the digital ground.

Unless you are able to experiment with connecting the oscillator ground to OSCVSS, I think that tweaking the circuit components will be your only option at this point.  There are boards where using the digital ground for the oscillator works, but the results are layout specific.

-Tommy

Ok, that's what I wanted to hear about the reason for oscillator ground separated from digital gnd. Naturally, my OSCVSS pads are connected directly beneath the OMAP chip so there's no way I could change the connection. I'll just have to stick to more gnd noise filtering and load cap tweaking and hope that my layout is among the working ones...

This is the thread I was referring to: http://e2e.ti.com/support/arm174_microprocessors/omap_applications_processors/f/42/t/34276.aspx?PageIndex=1

Thanks a lot for your help!

   Harri