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

6747 SPI0 boot stall

Thomas Bergfjord
Prodigy 50 points

I am trying to boot a 6747 (ROMID D800K005) from SPI0 connected to a flash (W25Q80BV), where an ais-file is previously flashed.

It is a custom board

This is what happens, when monitoring the SPI lines with an oscilloscope:

When the DSP is brought out from reset, it sets chipselect low, sends a read command (0x03) to the flash, followed by the 24-bit address (0x000000) and then reads in the first 3 bytes (0x54, 0x49, 0x50) from the flash. Then chip select goes high and nothing more happens.

This is very confusing to me. At least, it should read 4 bytes and check the ais magic number (0x41504954), but it only gets the 3 LSBs and then just stops.

The SPI clock is 1MHz and all signals are looking great. If the 6747 bootloader has come this far, I don't see what I have missed.

Could anyone please come up with a suggestion how to proceed?

Kind regards,

Pär

  • 0
    TI__Guru** 116170 points

    Thomas,

    Did you do a board validation on with a read/write test case for the SPI flash? IF yes, were you able to read and write to the SPI flash with out any issues.

    Is it possible that there is a hook up that can interfere with the signal on the SPI chip select SPI0_CS0? Can you connect to the device after the boot fails and run the debug GEL file to see if there is any feedback error code from the ROM.

    http://processors.wiki.ti.com/index.php/OMAP-L1x_Debug_Gel_Files

    Regards,

    Rahul

  • 0 in reply to Rahul Prabhu
    Prodigy 50 points

    Rahul,

    Thanks for your reply. The gel-file is really helpful!

    It appears thet we had a problem with our buffers when the bootpins were latched by the DSP. It was selecting boot from eeprom instead of flash, which explains why it looked as it was reading 3 bytes instead fo four. Eeprom has the same read command but only 16-bit addressing instead of 24-bit as the SPI flash has.

    A pull-up to the SOMI/BOOT-0 solved the problem and the DSP now boots from SPI0 flash.

    It gets a bit complicated since the DSP first latches the boot pins, which are shared with the SPI0, then acts as a SPI master during boot, and later as a SPI slave to a 28335 when the application is running:-)