• State Resolved
  • Locked Locked
  • Replies 15 replies
  • Subscribers 102 subscribers
  • Views 1347 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.

6657 EVM bootloader with SPI hangs after last word

John Gibbs
Prodigy 130 points


Hey all, I've managed to follow this:

http://e2e.ti.com/cfs-file.ashx/__key/communityserver-discussions-components-files/639/1452.Booting_5F00_from_5F00_SPI-NOR_5F00_C6678.pdf

to get a test image to boot from the NOR flash on the 6657 EVM.  When I try my actual image (which is larger, 112kB), the bootloader hangs at the very end, reading the word right AFTER my image over and over and over again.  The NOR flash responds with 0xFFFFFFFF, since this location is empty of course.

Any ideas?  Is there any way to check for some sort of error code in the bootloader?  Thanks

John

  • 0
    TI__Guru** 116560 points

    Hi John,

    Can you please provide the Program counter value when this issue occurs. This should help us understand the function in the ROM code in which the code is hung.Do you mean that you are able to load in smaller images but this issue occurs only when you try larger images? Did you have any warnings while building the bootimage that indicate that you may have exceeded the size limit on any of the utilities provided in the MCSDK. If yes, you may want to change the size limits in tools like b2i2c and romparse to meet your application requirements.

    One other thing for us to check would be that all the section load addresses and section size in the boot image match with what you see in your map file for the application to ensure that the ROM is not trying to read beyond the section length. We are currently working on s System debug GEL file for the platform that should allow us to take a snapshot of the device setting when a hang occurs. I will provide you a copy as soon as we have a version ready.


    Regards,

    Rahul

  • 0 in reply to Rahul Prabhu
    Prodigy 130 points

    Hi Rahul,

    The PC is 20B0EB90.

    I'm not terribly sure why some images boot and some don't.  The most obvious difference is size. I don't get any warnings from the utilities, and my image really isn't that large (100kB or so). 

    I was also working on a program that would parse the boot table and validate it like you suggest.  Thanks

    John

  • 0 in reply to John Gibbs
    TI__Guru** 116560 points

    Hi John,

    A few things that you can check :

    • Is all of the code and data sections in the application binary being placed in internal memory or are there symbols being placed in the DDR memory. That example doesn`t demonstrate how DDR is initialized so make sure the code is placed in internal memory.
    • After you see the boot fail, can you check if the rest of the application binary is loaded in memory correctly. YOu can check this by loading only the symbols of the application binary using CCS and inspecting the memory location where the application needs to be loaded as per your map file. Also confirm the value of location 0x008ffff0 matches with the entry point(_c_int00) of the application.

    If possible can you zip up your test code so that we can replicate the same on the EVM, that I have in my office. Please provide any additional information of how I can reproduce this issue.

    Regards,

    Rahul

  • 0 in reply to Rahul Prabhu
    TI__Genius 12595 points

    Hi Rahul,

    I'm working with John on this issue. Would the final linked .out file and map file help? I can provide those if so.

     

    -Brad

     

  • 0 in reply to Brad Caldwell
    TI__Guru** 116560 points

    Yes, if you can zip up the work area that builds the boot image. That may be helpful for me to replicate the issue. 

    Regards,

    Rahul

  • 0 in reply to Rahul Prabhu
    Intellectual 500 points

    HI Rahul and Brad,

    in http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/t/324168.aspx I opened a related topic and maybe you also know something about this issue.

    Do you know any reason why the PCIe PLL ist not locked (PCIE_SERDES_STS, bit0 = 0 - see SPRUGS6D, section 2.3.1.2) after booting in SPI mode (switches as in http://processors.wiki.ti.com/index.php/TMDSEVM6657L_EVM_Hardware_Setup#Boot_Mode_Dip_Switch_Settings, 

    ROM SPI Boot8 (off, on, off, off, on, on, on, on) (on, on, off, on, on, on, on, on)

    ).

    When I boot in "no boot"-mode the PCIe PLL is locked. Should I take care on something special during SPI boot?

    Regards, Gregor

  • 0 in reply to Rahul Prabhu
    Prodigy 130 points

    Hi Rahul,

    I'm not using DDR memory.  Is there a way I can attach a zip file to a private message to you?

    Thanks,

    John

  • 0 in reply to Rahul Prabhu
    Prodigy 130 points

    ....also, it doesn't look like anything is being loaded.  Locations where const data should be contain random data, and _c_int00 looks like garbage as well.  

    And I think my _c_int00 is at 0x88d960, not 0x8FFFF0.

  • 0 in reply to John Gibbs
    TI__Guru** 116560 points

    Hi John,

    We recently created an example for the EVM that demonstrates SPI boot and also DDR3 initialization using the RBL.I am sharing the example here, I have included a ReadME.txt document for you to replicate the example. I

    1050.SPIboot_ddr.zip

    am trying to do the same with the .out file you have shared with us to replicate the issue on the EVM. In the meantime can you try the example, I have provided and let us know if that works for you.

    Regards,

    Rahul

  • 0 in reply to Rahul Prabhu
    Prodigy 130 points

    Hi Rahul,

    I don't see a readme file anywhere.  In any case, I've already gotten the RBL to work using your procedure (see initial post).

    John

  • 0 in reply to John Gibbs
    TI__Guru** 116560 points

    John,

    I have re-uploaded the software on my earlier post. I have the ReadMe.txt file included in the package.

    Regards,

    Rahul

  • 0 in reply to John Gibbs
    Prodigy 130 points

    I'm trying to parse my boot table, but I'm totally confused.  This is my output from b2ccs.exe:

    1651 1 10000 1 6eeb
    0x0080c36f
    0x00000001
    0x00891480
    0x00000002
    0x00891480
    etc...

    From what I understand, the first 16 bits is the I2C packet length (0x0080, all ok), and the next 16 is the I2C packet checksum (0xC36F).  I think the next word is supposed to be the _c_int00 entry point, so obviously 0x00000001 can't be right.  Do you know what this is that I'm looking at?

    Thanks

    John

  • 0 in reply to John Gibbs
    TI__Intellectual 840 points

    Hi John,

    I believe I was able to get your boot image running correctly on the EVM.

    When I connected to the device after SPI boot, the PC was at 0x0084A8D8 and the symbols seemed to match with what had been loaded into memory and map file.

    I believe Brad or Rahul will be responding directly with a zipped up directory containing the images.

    Regards,

    -Jon

  • 0 in reply to Jon M
    Prodigy 130 points

    Hi Jon, that's good news.

    I'm looking at my hex file.  The first line is some funny ascii character, but the second line contains the _c_int00 entry as shown:

    00 88 D9 60 00 00 0B EC 00 89 E3 20 14 80 D1 01 00 05 D1 89 00 89 14 80 

    However, I've noticed that b2i2c.c completely throws away this line (it throws away the first two lines for no specified reason).  Why does it do that?  The third line of my .hex file starts with

    00 00 00 01 00 89 14 80

    which is in fact how my b2i2c output file starts.  

  • 0 in reply to John Gibbs
    Prodigy 130 points

    Ok I've got it to boot now.  Basically b2i2c.exe assumes the top two lines of the .hex file are garbage, even when they aren't.  So that's awesome.