• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 98 subscribers
  • Views 575 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.

L137 doesn't reliably boot from Flash on SPI0

Chip Slinger
Prodigy 110 points
Other Parts Discussed in Thread: OMAP-L137

We have a custom OMAP-L137 board that does not always boot out of SPI0 Flash memory. When it does not boot, we have observed with a scope that there is no activity on the SPI pins. However, we can access the pin scan chain through a JTAG tool and can change the SPI pins that way. When the system does not boot, we do not have a way of examining the processor internals to gain further insight into the failure cause.

When the system does boot, it seems to run our code fine and everything else we have so far checked out in the system appears to work, including UART, sync serial ports, SDRAM, general purpose I/O.

The crystal is running fine at all times; the osc caps are wired to OSCVSS. We believe that we have the bootmode pins configured correctly (SPI0_MISO=high, SPI0_MOSI=low, SPI0_SCK=high, BOOT7=low).. We have monitored their state at reset with a scope to make sure that they are not changing.

We have good clean power, bypassing and proper power sequencing. We have tried running the board off bench supplies to make 100% sure that the supplies are sequenced correctly, but do not see a difference. We have a reliable reset signal.

If the board powers up and boots, we can hit reset any number of times and the board will continue to boot reliably out of the SPI Flash. If the board does not power up and boot, we can very rarely make it boot by placing a scope on the flash control lines or by hitting reset, but mostly not (this could be just coincidence, though). Again, once it boots, it will boot every time upon manual reset until the board is power cycled.

Any thoughts or suggestions on debug strategy would be greatly appreciated. Thanks.

 

 

  • 0
    TI__Expert 8785 points

    When the board fails boot, can you connect to the device via CCS?  If you can, can you provide us with the output from this GEL file: http://processors.wiki.ti.com/index.php/OMAP-L1x_Debug_Gel_Files? Please make sure that all other GEL files are removed before connecting to the device.

    --Christina

  • 0 in reply to clam
    Prodigy 110 points

    Christina:

    Thank you for your quick reply. We aren't using CCS.

  • 0 in reply to Chip Slinger
    TI__Expert 8785 points

    Is there a way to connect the device on a bad boot, and read out some registers?  It would give us more insight to your issue.  For instance, where is the Program Counter when the board fails boot?

    --Christina

  • 0 in reply to clam
    Prodigy 110 points

    We don't have a way to do this. If necessary, I can probably arrange to get a windows machine and install CCS, but that is a pretty big sidetrack from our current development path.

    Do you have any other thoughts or suggestions as to things to look at?

    - C

     

  • 0 in reply to Chip Slinger
    TI__Guru 62975 points

    Chip,

    It looks like you have tried most of the common external component debug steps.  Given the problem description, I do not think that we will be able to provide productive debug suggestions without learning more about what is happening inside the device when it fails to boot.

    -Tommy

  • 0 in reply to tlee
    Prodigy 110 points

    Under CCS 4.2.0.10018 running on Windows XP and in a freshly created workspace, we created a new Target Configuration, selecting Texas Instruments XDS100v2 USB Emulator as the connection and OMAPL137 as the device.  We then started the debugger, clicked on the line in the debugger listing saying "Texas Instruments XDS100v2 USB Emulator_0/C674X_0 [Non-Project Debug Session]", then Tools -> GEL Files, then removed default "dskda830_dsp.gel" file.  Similarly, we removed the gel file from the debugger line mentioning ARM9_0.  We then clicked on the C674X_0 line again, and loaded OMAPL1x_debug.gel.


    We then connected our Spectrum Digital XDS100v2 adapter to the 14 pin connector on the Spectrum Digital L137 eval board, and clicked Target -> Connect Target.  The first time always pops up a notification "The target is being held in reset.  The applied reset must be released before progressing"  We press and release the white reset button, then click Retry.  The console window then prints about 40 lines of plausible information (rom id d800k003, silicon revision 2.0, boot mode spi0 flash, etc).  We note that we can unplug and re-plug the jtag cable and repeat Connect Target and each time get good output on the console.

    When we move the cable to our own board, either in the same session, or after going through the above steps with a fresh launch of Code Composer Studio, after we click Connect Target, we always get a popup saying:

    Error connecting to the target:
    Connect to PRSC failed

    There is a Retry button, but it just causes the same message to be repeated.  If we then move the jtag cable back to the eval board, we get the "PRSC failed" error message when trying to do Connect Target to it.  We have to exit and re-launch Code Composer to get it to work with the eval board again.

    Google searches of the "Connect to PRSC failed" message don't turn up any hints.

    We know the jtag connection itself works: if we plug a flyswatter jtag interface in our board (using flyswatter's beagleboard cable adapter), we can use the urjtag program running on linux to read the device id, and to toggle an led that we have connected to SPI1SCS0n_UART2TXD_GP513