• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 101 subscribers
  • Views 436 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.

OMAP3530 CUS Package Boot Issue

ler
Expert 1070 points

Hello,

I have a working 3530 CBB package design.  I recently moved to the CUS package to relieve some of the layout

issues.  I am bringing up the new design, trying to load x-loader and u-boot from the SD card.  I see the ROM code

communicate with the SD device.  Occaisionally, the board will load both applications from the card and attempt to boot.  Most of the

time, communication with the SD device is observed, but the x-loader doesn't seem to load.  To me it is almost like a connection

is missing to the new OMAP package but I can't quite figure out what it would be.  Does anyone know how to debug the ROM code

to find out why the OMAP isn't happy?  I believe I am close as it will boot once is a while, but I don't have access to the ROM organization.

Is there a different what to troubleshoot booting from SD?

Thanks.

 

 

  • 0
    Expert 1070 points

    As a follow-on to the above question:

     

    We have verified that the OMAP is indeed reading the xloader from the SD card (everytime).  However, the device only outputs

    the xloader banner (runs) about 1 out of every 10 times.  We feel we have a good SD interface.  Just doesn't seem to want to

    reliable run the xloader code.  Any suggestions on what could be the problem or how we might debug this?

     

    Thanks.

  • 0 in reply to ler
    Prodigy 200 points

    If you have Code Composer, it might be interesting to see whether it's really the ROM code that's dying or maybe xloader dies (i.e. before outputting the banner message).  That can be done by setting a hardware breakpoint at the very first instruction of xloader (probably 0x40200800, but check to be sure so you can be confident what it means if the breakpoint doesn't trigger [:)]).

     

  • 0 in reply to Ken Brown13794
    Expert 1070 points

    Thanks for the help.  What we did was to embedd an infinite loop in the x-loader startup code.  This allowed us time to grab the OMAP with the emulator

    before it locked up.  What a difference it makes when you can get JTAG to work.  We're off an running.  Thanks.

  • 0 in reply to ler
    Prodigy 200 points

    so xloader was always getting launched, but sometimes it would crash and sometimes it would work ok?

     

    Glad to hear you're unstuck!

     

  • 0 in reply to Ken Brown13794
    TI__Guru*** 125430 points

    Do you have a series resistor on the clock line?  The I/O cell drives very strong for the MMC interfaces and causes some nasty reflections.  This can cause the device to sample the pins at the wrong time and get bad data.  FYI, this is mentioned in this article in the "other considerations" section.

    Did you find the root cause of your problem?  It's not clear to me if the issue was bad code in x-loader/u-boot or if you just stopped trying to find the issue and work on something else for a while.  If it's the latter I highly recommend you see if you're using a series resistor on the clock signal as that may be responsible for your issues.

  • 0 in reply to Brad Griffis
    Expert 1070 points

    What appears to have happend, is that the 32KHz clock that feeds the GPTIMER1 is noisey.  This in turn caused the

    code that detects the system clock frequency (get_osc_clk_speed) to return erroneous values from time to time.

    We do have a series resistor in the clock line.

  • 0 in reply to ler
    TI__Guru*** 125430 points

    Thanks for bringing that info back to the developer community.  I'm sure that will help many others!