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.

DSP errata confirmation

Hello ,

I am from Sundance DSP Inc. We have a module from 4 or 5 years ago which recently we had to be redesigned and change the PCI interface to PCIe via an XMC connector. Here is the link to the old module: http://www.sundancedsp.com/pmc/xmc-modules/dsp417 and you can see its image by clicking on the picture of the board. And here is the image of the new board:

 

 

 

In the new design our PCIe interface works well but the bit of design that concerns TI DSP seems to have become unreliable and sometimes does not work. Note that we have not touched that part of the design at all. We found the silicon version errata for the DSP http://focus.ti.com/lit/er/sprz216i/sprz216i.pdf which states the following for silicon version 1.0 (used on the 417)

 

Power Sequencing − IO Before Core

If customers are using IO before Core, which was initially supported, it is required to connect the Reserved pin

W25 to ground due to insufficient pulldown strength. If IO comes up before Core, and W25 is not at ground level, this can result in the device coming up in an improper state. To ensure this does not occur, it is required to connect

W25 to VSS. If this is not done, then the power sequencing must be changed to Core before IO to ensure the internal state is set properly.

 

Anyone has experience with this and could say this is the cause of our problem? Sadly we have not connected that pin to anything and if this is the cause then we may need to change PCB unless if there is another solution you can recommend.

 

We are also looking for a consultant with detailed knowledge and experience of C6416 designs. Please call me on 775 8273103 if you can help.

 

Thanks for your help.

 

Nory 

 

 

 

 

  • Nory,

    The symptoms of the errata is that boot will not have completed on the DSP as the device can get stuck in a test mode, and this is extremely rare that this would occur. 

    When the failure on your board occurs you can connect CCS and verify if boot has actually completed (and code has loaded.)  If the boot has completed then the issue with the errata item mentioned has not occured and you'll want to start investigating whatever area's you're observing the failure on.

    For example, If the failure is in how the FPGA reacts post boot, then you'll want to check the FPGA image post boot.   I can make more suggestions here if you provide more details regarding the failure mechanism.

    Best Regards,

    Chad