• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 102 subscribers
  • Views 883 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TMS320C6678: Stuck in ROM Bootloader while trying to Boot from SPI NOR Flash

David Hague
Intellectual 560 points
Part Number: TMS320C6678

I've got an image that was built to boot from SPI Flash.  This image boots from SPI with no issues when burned to the SPI Flash of the Eval board, with the jumpers set to boot from SPI.  However, on our custom board, the image does not boot up.  I've connected to the target with code composer and I can see that the processor is stuck in a big loop in the RBL between addresses 0x20b0a26c and 0x20b0a338.  Can someone tell me what the RBL is not happy about?   I've read the DEVSTAT register and it seems to be correct.   I can also run code (from CCS) on the target that reads and writes to SPI flash with no problems.  Oh, and I can also run the same image from CCS on the target that I'm trying to boot from SPI and it runs okay.

  • 0
    TI__Guru 65405 points
    The team is notified. They will post their feedback directly here.

    BR
    Tsvetolin Shulev
  • 0
    TI__Guru** 114410 points
    David,

    Can you please elaborate regarding the differences between the EVM and the custom board design? Also, are you using the same image and the flashing tool and DEVSTAT settings as the EVM? Most likely reason that SPI boot fails on this device is that the boot image is not flashd with the correct byte ordering which is a function of how the boot image creation utilities generate the image and the how the flashing tools program it to the flash. From the memory locations of the hang, the ROM code is hung in the hw_spi_xfer and hwSpiRead functions so it does seem to be booting in the right boot mode.

    Regards,
    Rahul
  • 0 in reply to Rahul Prabhu
    Intellectual 560 points

    Sadly, I'm not totally positive about the differences between the EVM and the custom board.  Most of our code developed on the EVM has run on the new board without issue.  We do have a custom FPGA that we talk to but when loading our code from the CCS debugger we can do that with no issues.   The image in question is the same one I'm burning on the EVM and the custom board.  The flashing tool I'm using is the exact same one, that was modified from your original norwriter_evmc6678l TI tool.  When I load the image from the CCS debugger and read the DEVSTAT register, it reads the same on both boards.  I would think that the endianess would be correct since it is the same processor on both boards.

    Thanks for the info about the loop I was stuck in.  Can you tell me what might keep the RBL stuck in that loop indefinitely?  Is it getting some error condition that would cause it to loop forever?

    One new development.  While we were probing the board to see if the SPICLK, SDA, and MISO/MOSI lines were active, we suddenly discovered that the image was in fact booting.  I certainly didn't change the image that was burned to Flash, but we cycled power several times and each time the image booted.  What changed?  Why did it suddenly start booting?  I don't know.  I'll keep investigating but I don't like it when something starts working unexpectedly because it just as easily stop working.  If you could give me insight as to the nature of the RBL loop I could maybe figure out why it suddenly got out of that loop and booted my code.

    Thanks,

    David