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: SPI boot doesn't start

Part Number: TMS320C6678

Hello,

We are designing a new board with a C6678 which boots from a NOR Flash (S25FS064S). As you can see in the image below, the SPI boot starts, 8 bytes are sent. The first byte sent by the DSP to the Flash is 0x0C which is a read command followed by 4 bytes address (0x00000000). So far everything look good but I don't understand the 3 other bytes from the Flash. After this sequence nothing...

 

1 -> Chip select
2-> MOSI
3-> MISO
4-> SCLK

After a few seconds, few minutes (delay vary) the DSP finally boots... The power supplies are all good, reset lines are high and input clock is 100MHz. Any idea why this happens or where to search?

Thanks,

Hugo

  • A little modification in my previous message:

    The read command is 0x03 and the next 3 bytes are the address (0x000000). But still why doesn't it boots?

    Hugo
  • Hi,

    I've notified the RTOS team. They will post their feedback directly here.

    Can you share which TI RTOS SDK version are you using?

    Best Regards,
    Yordan
  • Hi,

    RTOS: 6.46.5.55
    SDK: 4.00.00.04
    PDK: 2.0.6
    XDC: 3.32.1.22

    Thanks,
    Hugo
  • Hi,

    We found out that pin PCIESSEN was pull high but its PLL wasn't set as we are debugging the board and PCIe PLL has not been setup yet in software. By pulling down PCIESSEN, DSP boot normally.

    What's funny and that we don't understand is that DSP was always booting even with PCIESSEN pulled high with no PLL but it was booting after a few seconds (not less than 15-20 seconds) or up to a few minutes and this time was never the same... Weird!! Can anyone explain that?

    Thank
    Hugo
  • Hi Hugo,

    Since the PLL is not configured, I am assuming that the clock is in bypass(low frequency) mode so booting takes some time. 

    Thank you.

  • Hello Rajasekaran,

    Boot mode is SPI. But the funny thing is that boot time is never the same and can take up to a few minutes when pin PCIESSEN is not pulled low.

    Regards,

    Hugo

  • Hi Hugo,

    I am confused, what is the meaning of DSP boot normally(normal speed and consistent) when the PCIESSEN pulled low?
  • 1. Are you working on direct SPI boot or IBL based NOR boot?

    2. Are you working on EVM or custom board?

    3. Can  you try the example available in below wiki page,

    Thank you.

  • Hi Raja,

    DSP boots normally means that code is loaded from NOR flash to DSP RAM (no DDR) and starts executing code normally with normal speed and consistent. When I talk about DSP doesn't start in my first question, it means that code is not loaded in the DSP. Only the first 4 bytes are read from NOR flash but then nothing for up to a few minutes (see first post).

    Answers to your questions:

    1. No IBL

    2. Custom board

    3. To be honest I don't think this will change anything since the problem happens before code is loaded in DSP therefore whatever the application is, it won't change anything.

    Thanks,

    Hugo

  • Hi Hugo Bouchard,

    Are you still working on this issue? As per your previous posts - Pulling down PCIESSEN, DSP boot normally right. I hope this workaround helps to move on. Please confirm.
  • Hi Raja,

    Yes the workaround works but I would have liked to understand why the DSP boots after a random time (up to a few minutes) when PCIESSEN is not pulled down.

    Regards,

    Hugo

  • Hugo,

    Do you see this issue more then one custom board? Is it possible to reproduce your issue in EVM?
  • Hi Raja,

    Yes we have the problem on all our custom boards. I haven't tested with the EVM board and no time to do so as the workaround works, we have to move forward in our development. I guess this is something you can do. You just need to pull PCIESSEN high, make sure no PCI clock is generated and try to boot. This is not software related. It looks like a bug in the BootROM.

    We don't want to investigate deeper this issue as the workaround works. If you would have had an explanation we would have been interested. If you consider that its not useful for TI to understand this issue than you can close it but we are not going to do the investigation for you as the problem is not on our side. Hope you understand.

    Regards,

    Hugo