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.

TMS320C6671: Incorrect operation

Part Number: TMS320C6671


The board uses TMS320C6671ACYPA25 chip to run the DSP program online for many times, but the board does not start for many times. When it does not start, the DSP program operation is suspended immediately, and the DSP operation is stuck in the interface as shown in the following figure: Please consult the reason for this interface



  • Hello, The engineer (Sankari) responsible is currently out of office for next few weeks.

    Please expect 2 week delay in response.


  • Hello Praveen,

    Could you please help to handle it as soon as possible? It's quite urgent as there have been several cases of this situation. Thank you very much



  • Hello Gary,

    board does not start for many times

    This seems to be a board issue. Have tried using a different board? Note sure what is the expectation here.


  • Hello,

    When running the DSP program online and pausing the DSP program, this situation appears on the interface. The board has already been in mass production, and two boards have recently experienced this situation. I would like to know if 6671 has such a fault and if you can provide ideas to solve it



  • Gary,

    Out of how many boards, these two boards are getting failed?

    In a mass production, if all the boards are getting passed and only two are getting failed, it is most likely a hardware issue. ( I mean, "board issue" and not a "processor chip - C6671" issue)

    Compare the working board with the non-working board...


    In your snapshot, the error code seems to be "1202" while using the emulator - XDS100 V1.

    Please refer the below link for debugging the Jtag connectivity.


    From an old wiki content of this error-1202:-


    The application you are running has somehow locked up the C66x core - it could be waiting for a peripheral that never gets freed, or a memory bus contention that is never resolved. That is why power cycling the board, restarting CCS or reloading the code will not change the outcome.

    At the time of the error the debugger can still try to regain some control and halt the core, but your application will be in a corrupt state. At this point you will need a JTAG debugger to inspect the device memory and its registers to see if you can locate where the core is hung or how it got there. Also, If the application reaches main() before collapsing, then you could either step-by-step or even try to setup ETB trace and try to get at least some idea about the history of the lockup.


    Shankari G