• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 97 subscribers
  • Views 424 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Debugging sporadic OMAP3530 HW startup problem?

Bjorn Wesen
Prodigy 120 points
Other Parts Discussed in Thread: OMAP3530, TPS65920, TPS65950

Hi,

we have a custom OMAP3530 board, very similar to the beagleboard, using the TPS65920 power-companion instead of TPS65950.

Some times when we apply power to the board the OMAP3530 gets stuck and doesn't try to boot from either NAND, serial or USB, and it doesn't release nSYS_RESWARM.

To me this suggests that the bootrom is not executing (JTAG probe is on the way...)

Both 32khz and 26 MHz clock and all power-rails are working and the nSYS_RESPWRON from TPS65920 is released and is fine, when this occurs.

Re-powering OR activating a cold-reset (pulling nSYS_RESPWRON to GND) unfreezes the OMAP3530 and then it boots just fine (from either of the interfaces).

Any hints on where to look for something which can inflict this damage? As far as I understand, the TPS65920 should guarantee the correct power-sequencing and keeping nSYS_RESPWRON until the power is stable. 

This seems to occur only on the second of our two first batches of boards, so there is a possibility that any of the components for example a capacitor is mounted incorrectly by the manufacturer, something which is quite difficult to troubleshoot of course.. 

Thanks for any hints anyway,

regards,

Bjorn

  • 0
    Prodigy 120 points

    Adding some followup to my own post here:

    It seems that the root cause here is the 26 mhz xtal oscillator starting up too slow. The TPS65920 ramps up the power rails and releases SYS_RESPWRON at almost the same time as the 26 mhz clock is stable, causing problems at cold-boot (but powercycling or manually resetting works, because presumably then there is still some power left in the system somewhere to speed up the startup enough to happen just before the reset is released).

    So, the OMAP gets the reset released before the 26 mhz clock is stable. I assume this will cause it great pain.

    It is kind of frustrating to have a powerchip that can properly sequence all important power rails for the CPU but which does not include a wait for a stable clock.. Maybe that is difficult to design.. however, some kind of pin that says "do some extra delay" could have been a useful addition.

    regards

    /Bjorn

     

  • 0 in reply to Bjorn Wesen
    Genius 3685 points

    Hi Bjorn,

    Have you considered/tried using a crystal connected to the OMAP instead of using an external osciallator? Hereby  you could avoid the problem. Unfortunately all official platforms (I know of) today use an external oscillator as TI (to my knowledge) never really validated the OMAP crystal approach, eventhough it's supposed to work today AFAIK...

    Please as well have a look at http://e2e.ti.com/support/power_management/pmu/f/43/p/48505/228716.aspx#228716 for furthe rinforamtion

    Best regards
      Søren

  • 0 in reply to Soren Steen Christensen
    Prodigy 120 points

    Søren Steen Christensen said:

    Hi Bjorn,

    Have you considered/tried using a crystal connected to the OMAP instead of using an external osciallator? Hereby  you could avoid the problem. Unfortunately all official platforms (I know of) today use an external oscillator as TI (to my knowledge) never really validated the OMAP crystal approach, eventhough it's supposed to work today AFAIK...

    Please as well have a look at http://e2e.ti.com/support/power_management/pmu/f/43/p/48505/228716.aspx#228716 for furthe rinforamtion

    Best regards
      Søren

    Hi,

    actually, I designed both a discrete xtal oscillator and an integrated oscillator onto our board, and switching to the integrated oscillator (the Ecliptek from the BB BOM) solved the problem for now. However, as the thread you referred to also discussed, the actual spec for that oscillator is startup < 10 ms which is 5 ms too long really. I'm afraid to use this in production.

    We're looking at ways of tuning the discrete oscillator to start-up faster, but really, the main problem (and I guess this is the problem with the integrated as well) is the low power supply of 1.8v. Going up to higher voltages decreases the startup time in both cases.

    So, for the next PCB spin we'll add an external delay of the reset, and either put an oscillator on one of the higher power-levels on-board or just go with the lowest cost of the current alternatives.

    This issue should be marked much more heavily in both the TPS659xx design-in guide and the OMAP3 techref.

    Regards,

    Bjorn W

    Thinking Eyes AB, Lund, Sweden