• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 53 subscribers
  • Views 1757 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.

Bad Silicon Revision Error TMS320C6713B via XDS510USB+

Christopher Fleck
Prodigy 130 points

Other Parts Discussed in Thread: TMS320C6713B

TI Correspondent,

First, some system settings:
- Windows 7, 64-bit
- Code Composer Studio v5.2.1.00018
- TI TMS320C6713B DSP/Spectrum Digital TMDSDSK6713 Development Board
- Spectrum Digital XDS510USB+ JTAG emulator

We have developed a custom board in-house that uses the TMS320C6713B processor. We are able to consistently pass a JTAG scan test via SDConfig.exe or CCS, as suggested by Spectrum Digital's JTAG emulator FAQ (http://support.spectrumdigital.com/guides/JTAG_Emulator_guide/). Attempting to connect to the device (to program the device) via the XDS510USB+ JTAG emulator, we get the following error:

TMS320C671X: Error connecting to the target: Error 0x80000200/-1063 Fatal Error during: OCS,  Bad Target Silicon Revision Number Please check your multi-processor configuration. The number of devices in the JTAG scan path must be correct for the silicon revision to be read. Or, you may have selected the wrong DSP device driver.

We also have a Spectrum Digital TMDSDSK6713 in house, and are able to properly connect to this DSK. We're using the same settings and programming pod that raise the "bad silicon revision" error on our custom board.

We've scoped out the signals at the JTAG connector for both the DSK and our custom board, but they seem to have similar operation, so we're at a loss as to what might be causing the issue. We've followed the suggestions for JTAG operation here (http://processors.wiki.ti.com/index.php/XDS_Connector_Design_Checklist) and here (http://processors.wiki.ti.com/index.php/XDS_Target_Connection_Guide).

A few things we've tried:
1] Connecting the TRST and RST signals for the DSP to force reset (per a recommendation on page 95 of the C6713 datasheet)
2] Connecting to the programming pod using all four TCK modes enumerated by CCS
3] Forcing a target/programming pod reset via CCS
4] Starting a new CCS project wherein the only code is a blank main() routine

Do you have any suggestions for debugging?

Thanks,
-Chris

  • 0
    TI__Guru**** 171839 points

    Hi,

    I have a DSK with the 6713B device and was able to connect to it using my XDS510USB (not plus, unfortunately). Therefore we can rule out anything related to the tool itself.

    During my tests I got the exact same error as yours (in my case I was inadvertently using a C674x configuration), but I also noticed this could come from the fact the emulator cannot properly access the ICEPICK (the JTAG router) registers to identify the device. In this case:

    - Can you check if you can manually connect to the ICEPICK? For details please check this discussion.

    - Can you carefully inspect your .ccxml file and see if you are configuring it for the TMS320C6713? Maybe attach it here so I could test it as well...

    - I think the XDS510+ emulator has the ability to control the TCLK speed - you can try to reduce it, but I am not really sure if that would help; 

    I see you already compared the waveforms between the two systems, therefore I was inspecting the DSK schematics to see if anything strikes as a potential issue and different than what you reported - if you haven't done so, I suggest you do the same...

    I will try to think of additional ideas and get back to this thread, ok? In the meantime maybe someone else hit a similar issue and may give some comments.

    Hope this helps,

    Rafael

  • 0 in reply to desouza
    Prodigy 130 points

    Rafael,

    It turned out that another module on our custom board was overdriving the EMU[1:0] lines for the C6713. During normal operation, this other module would keep it's control of those lines in high impedance. An error, though, that we were debugging with this other module turned out to be holding it in reset, during which it asserts an EMU state which turned out to be invalid for programming the C6713.

    Fixing the error with the other module let the EMU lines take their proper state during normal operation, and we were able to successfully program after that.

    Sorry to have caused you trouble with this matter.

    Thanks,

    -Chris