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

TMS320C6678: PCIe boot localReset failed

Shine
Genius 13655 points
Part Number: TMS320C6678

Hello,

Customer failed to run the C:\ti\mcsdk_2_01_02_06\tools\boot_loader\examples\pcie\pcieboot_localreset example code on C6678 EVM from Trolong. There is no modification for the example.

PCIe boot mode is successful. Then localReseting DSP, reloading the code, only Core0 can run the newly loaded code. Core1~core7 can't run the new code.

Connecting JTAG to view the boot magic address. After local reseting, only core0 boot magic address is 0, core3 and core4 boot magic address are 0 sometimes, other cores' boot magic address aren't changed.

Why? Is there something missed?

Thanks.
Rgds

Shine

  • 0
    TI__Guru* 95265 points

    Hi,

    This needs some debug where it didn't work on other cores. In the Linux host side, there is a pciedemo.c:

    for (i = 0; i < 8; i++) {
    pushData(localResetCode, i, &bootEntryAddr);
    if (setBootAddrIpcgr(i, bootEntryAddr) == 0) {
    printk("Core %d is not ready !!! \n", i);
    }
    }

    After the boot failure, if you look at the cores with JTAG, did you see the localresetcode in each L2 memory? That is the PCIE download the code successfully to each DSP core? Then look at the DSP_BOOT_ADDR (0x2620040+4*n), did you the start address written there? If yes, the DSP should start to execute from there (it is your _c_int00).

    Assuming DSP core didn't run the code, where is the program counter? You can check with *.map to understand what happened?

    Regards, Eric

  • 0 in reply to lding
    TI__Guru* 95265 points

    Any update?

    -Eric

  • 0 in reply to lding
    TI__Genius 13655 points

    Hi Eric,

    Thanks for your great support.

    I haven't heard from the customer by now. You could close the case. 

    Thanks.

    Rgds
    Shine

  • 0 in reply to Shine
    TI__Genius 13655 points

    Hi Eric,

    Sorry to disturb you again. I received the reply from customer.

    Customer found that some DSP_BOOT_ADDR (0x2620040+4*n) address are at _c_int00 , some address are at 0x20B00001. 

    Thanks.
    Rgds
    Shine

  • 0 in reply to Shine
    TI__Guru* 95265 points

    Hi,

    If for some reason the driver didn't write the _c_int00 into DSP_BOOT_ADDR reliably, they may read it back to make sure it is written.

    Regards, Eric

  • 0 in reply to lding
    TI__Genius 13655 points

    Hi Eric,

    Customer wrote the _c_int00 into DSP_BOOT_ADDR and read it back, it works. But if he didn't read back the DSP_BOOT_ADDR after writing, it still can't work.

    Thanks.

    Rgds

    Shine

  • 0 in reply to Shine
    TI__Guru* 95265 points

    Shine,

    Thanks for the info! Looks some reliably issue when writing over PCIe, which is posted. The value didn't landed on time (it is still in the C6678 PCIE Rx buffer) on end memory point. When you do a readback, it helps to make sure the write transaction to finish. Please use readback as a workaround.

    Regards, Eric