• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 99 subscribers
  • Views 1114 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.

platforminit() on C6657

Martin Hantke
Intellectual 825 points

Hello Community,

i sucessfully flashed my application to the external SPI-Nor with the given examples from this forum.

As i understood the device is then configured properly so i do not have to call platform_Init() again?

Many thanks for your answers

Regards martin

  • 0
    Intellectual 825 points
    Sry i have to give additional information:
    The application is stored in external SPI-Nor with Boottable to configure DDR.
    I see the .emif4Cfg in the map file and the Hex6x-utility also translates it.
    when i power-cycle the board with correct dip-switch settings (load from spi-nor) i see the PC on locations of the DDR.

    i then load the symbols RUN->Load Symbols and see _c_init00() and main() @ the correct locations as in the map-file given.
    Regards martin
  • 0 in reply to Martin Hantke
    Intellectual 825 points
    Further Information:

    i figured out that i have to push the "Warm Reset" Button after POR.
    After pushing the button i see my LED-Blinking on TMDXEVM6657L .
    Does someone Knows why, or can provide a source where i can read more?
    Thanks and regards martin
  • 0 in reply to Martin Hantke
    TI__Guru* 81335 points
    Hi Martin,
    I am confused. I understood that you were able to boot successfully from SPI NOR directly with DDR initialized. Please confirm.

    Can you please conclude the issue or problem in a post? Which example?

    Thank you.
  • 0 in reply to Raja
    Intellectual 825 points
    Hello Raja,
    first many thanks for your quick reply.

    Yes i can confirm that may application is loaded directly from SPI-Nor to the DDR. (i am happy now)

    (All steps with converting by usage of "b2i2c", "byteswapccs", "romparse" are working now.)


    My Application now does all what it normally do in Debug-Mode.

    The only thing i do not understand is:

    Why do i have to do a warm reset after POR?
    Can i provide a warmreset by my Application or has it be done from external?

    I tested this behavior now several times.

    Regards martin
  • 0 in reply to Martin Hantke
    TI__Guru** 116100 points
    Dear Martin,
    What is your EVM version ?
    I heard that older version of EVMs need warm reset for the successful flash boot since it might stuck with IBL code, when you do warm reset then it will come out from IBL (stuck up problem) to RBL and execute the code from flash.

    Actually we use IBL code for the PLL workaround due to RBL issue in older EVMs.
    So the procedure would be, FPGA would force the RBL to boot from IBL and applythe work around then jump to RBL again and execute the actual boot mode (NAND or NOR etc.,)
  • 0 in reply to Martin Hantke
    TI__Guru* 81335 points

    Hi Martin,

    As per my understanding, there is no external reset required to boot from SPI NOR.

    1. The boot workaround is applicable to NAND boot on C6657. Refer below,

    Booting from a NAND flash device will fail when the C6657/C6655 at full speed. The root cause of the problem is that insufficient time is allowed for the NAND device to complete the initial reset command sent to it by the DSP ROM code. After sending the reset command, the DSP executes a wait loop(for time out). This wait loop allows a maximum number of iterations before halting and declaring that the NAND is not responding correctly. The wait loop does not allow enough time for the NAND to complete its initial reset sequence.

    Proposed work arounds:

    • Use the FPGA firmware on the system to first apply reset to the NAND flash device and then apply reset to C6657 device after the NAND device is ready.
    • After a POR of the devicie, apply CPU reset. The CPU reset only restarts the RBL and allows the NAND flash device to complete its initial transition out of reset. This will work because NAND devices complete the second and subsequent reset sequences faster when compared to the initial reset sequence (5 micro-seconds vs. 300 micro-seconds) NAND boot can be made to work by simply taking C6657/C6655 back into reset and then releasing it from reset. This extra reset sequence must be done without cycling power to the NAND device. Resetting C6655/C6657 after an initial NAND boot attempt works since the wait loop is long enough for success on a second boot attempt)


    Few threads:

    2. Many customers able to boot from SPI NOR(direct) on C6657 EVM without the external reset. To isolate the issue, I recommend you to boot the SPI NOR led_play without DDR. The led_play examples is part of the KeystoneI_bootloader_workshop.zip.

    Thank you.

  • 0 in reply to Raja
    Intellectual 825 points
    Hello Raja,
    I believe we get this issue fixed.
    Many thanks for your answer here.
    Unfortunatelly my applications is too big to fit in the internal memory so we have to use DDR.
    Due to the fact that we additional have a secondary µC we fix that by doing a warm reset after POR.
    atm this is my smaller problem.
    Many thanks again.
    Regards martin
  • 0 in reply to Titusrathinaraj Stalin
    Intellectual 825 points
    Hello Titus S.
    thanks for your reply.
    I have here Revision
    PCB: 17-00132-02
    PCA 18-00132-02
    We will see on our custom board what happens.
    We do not use an external FPGA but an external µC.
    Thanks for this hint on the issue.
    Regards
    martin