• State TI Thinks Resolved
  • Locked Locked
  • Replies 13 replies
  • Answers 1 answer
  • Subscribers 53 subscribers
  • Views 1737 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CCS/TMS320DM6433: USB560V2

Stuart Tenenbaum
Prodigy 150 points
Part Number: TMS320DM6433

Tool/software: Code Composer Studio

We have a mature product based on the TMS320DM6433.  The product was developed using CCS V6.x and debugged with a Blackhawk USB560V2 JTAG debugger.  As we begin development of a new product, we decided to upgrade to CCS V7.  In conjunction with this upgrade, we switched our legacy product to CCS V7 as well.  Since making this switch, my debug environment has become completely unreliable.

The initial install of CCS V7 had trouble due to the Blackhawk driver signature.  Disabling the requirement for driver signatures in Windows resolved this problem.  I can connect to my target with the Blackhawk JTAG debugger, but it doesn't run properly.  While stepping through code it often 'quietly' disconnects.  That is, no error message is displayed, but code execution stops and variables/memory are not accessible.  Often while debugging, the code gets 'stuck' in a printf output loop in which I assume it is trying to send data via USB back to the PC.

Everything works fine if I switch back to CCS V6 on the same computer and using the same Blackhawk debugger.

My system specifics are:

  • Windows 10 Pro, 64 bit, V1709 Build 16299.309
  • CCS V7.4.0.00015
  • Blackhawk Driver V6.2.0.009

I must have my environment running under CCS V7 as it is used by the rest of the developers in my department.  Any suggestions would be greatly appreciated.

Regards.

  • 0
    TI__Guru**** 420520 points

    Hi Stuart,

    Stuart Tenenbaum said:
    The initial install of CCS V7 had trouble due to the Blackhawk driver signature.  Disabling the requirement for driver signatures in Windows resolved this problem. 

    I think this issue popped up when a Windows 10 patch was applied. That was the case for me. As per Blackhawk's recommendation, I had to disable something in the BIOS to allow me to workaround this

    Stuart Tenenbaum said:

    I can connect to my target with the Blackhawk JTAG debugger, but it doesn't run properly.  While stepping through code it often 'quietly' disconnects.  That is, no error message is displayed, but code execution stops and variables/memory are not accessible.  Often while debugging, the code gets 'stuck' in a printf output loop in which I assume it is trying to send data via USB back to the PC.

    Everything works fine if I switch back to CCS V6 on the same computer and using the same Blackhawk debugger.

    This is difficult to debug. I have the same debug probe and it has been quite reliable for me when using CCSv7. Are the blackhawk drivers the same version in both CCSv6 and CCSv7 (did you update the blackhawk drivers in CCSv6)? Are you using the same target configuration file between the two CCS version?

    Thanks

    ki

  • 0 in reply to Ki
    Prodigy 150 points
    Hi Ki,
    Thanks for your quick response. You're right about the driver problem occurring in conjunction with a Windows 10 update. I too was instructed by Blackhawk to disable driver signatures in my BIOS.

    I am using the same CCXML and GEL files between CCS V6 and V7. Perhaps noteworthy is that my colleagues have Blackhawk driver V6.2.0.007 and their debug environments work fine. I have V6.2.0.009. My understanding (per Blackhawk) was that version 009 of the driver fixed the signature problem. However, on my computer, version 009 did not fix the driver signature problem.

    What version of the Blackhawk driver are you running? Any suggestions?

    Thanks.
  • 0 in reply to Stuart Tenenbaum
    TI__Guru**** 420520 points

    Stuart Tenenbaum said:
    Perhaps noteworthy is that my colleagues have Blackhawk driver V6.2.0.007 and their debug environments work fine.

    This is for CCSv7 also? Does your probe work fine in their CCSv7 environment?

    Stuart Tenenbaum said:
    What version of the Blackhawk driver are you running? Any suggestions?

    I actually have Blackhawk driver version 6.2.0.008. I will update to .009 and see if I notice any issues

    Thanks

    ki

  • 0 in reply to Ki
    TI__Guru**** 420520 points
    I updated to BH driver 6.2.0.009 recently on CCSv7.4. I have been playing around with it for awhile and so far I have not run into any issues. Are the issues you encounter pretty sporadic or do they occur very often and quickly?

    Did you have a chance to try your probe on your colleague's CCSV7 environment?

    Thanks
    ki
  • 0 in reply to Ki
    Prodigy 150 points

    I cannot debug on my machine for more than a couple of minutes, a few breakpoints, or a few line steps through code.  The problem happens quite regularly.

    I have tried my Blackhawk USB560V2 probe on several other machines and it works fine.  I have also tried other probes on my machine and they exhibit the problem (quiet disconnect).

    Thanks,

    Stuart

  • 0 in reply to Stuart Tenenbaum
    TI__Guru**** 420520 points

    Stuart Tenenbaum said:
    I have also tried other probes on my machine and they exhibit the problem (quiet disconnect).

    were any of these different probes? Non-Blackhawk probes?

    Would it also be possible to generate a debug server log and attach it to this thread?

    http://processors.wiki.ti.com/index.php/Troubleshooting_CCSv7#Debug_Server_Logging

    Thanks

    ki

  • 0 in reply to Ki
    Prodigy 150 points

    Over the past several days I have tried to capture the failure with debug logging enabled.  The system doesn't seem to fail under these circumstances.  Could this be a clue as to the source of the problem?

    Thanks,

    Stuart

  • 0 in reply to Stuart Tenenbaum
    TI__Guru**** 420520 points
    The only thing that logging would really do (besides collecting diagnostic messages) is slow down the debugger.

    Is this behavior pretty reproducible:
    -logging OFF and emulation connection is unstable
    -logging ON and emulation connection is reliable
    ?

    Thanks
    ki
  • 0 in reply to Ki
    Prodigy 150 points

    6013.ds.zipHere's a log file from a quiet disconnect.

    Stuart

  • 0 in reply to Stuart Tenenbaum
    Prodigy 150 points

    Here's a much shorter log file with the quiet disconnect error.

    6064.ds.zip

  • 0 in reply to Stuart Tenenbaum
    Prodigy 150 points

    Here is one more log file with several failures over a short period of time.  Do these log files shed any light on the problem?  Obviously my productivity has come to a screeching halt since I can only debug for a few minutes or seconds at a time before I have to restart the debugger (at best) or, quite often, exit and restart Code Composer.1376.ds.zip

  • 0 in reply to Stuart Tenenbaum
    TI__Guru**** 420520 points
    Thanks for the logs. One of the logs shows an issue with the debugger trying to unwind the call stack. It happened when stepping over a breakpoint at 0x87D834C8. What is at that address? Would it be possible to obtain your *.out file for further analysis? You can sent it privately if you wish via private forum message

    Thanks
    ki
  • 0 in reply to Ki
    TI__Guru**** 420520 points
    Thank you for providing the executable. We were able to find the root cause of the debugger instability that was in the debug server logs. It looks like an issue with the debugger when trying to unwind the callstack at a specific point in the application.

    I have filed a bug for this. Tracking ID: CCBT-2250

    Hopefully this is the issue. I am a little befuddled why your colleagues were not able to reproduce in CCSv7 while you were able to. But hopefully a fix for the above issue will address the instability you witnessed

    Thanks
    ki