• State TI Thinks Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 2108 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.

CCS/AWR1642BOOST: CCS disconnects from radar after sensorStart

David Murdoch
Prodigy 120 points
Part Number: AWR1642BOOST
Other Parts Discussed in Thread: AWR1642, IWR1642

Tool/software: Code Composer Studio

Hello, 

When I load demo programs onto an AWR1642 using CCS, the program runs fine during configuration before sending a sensorStart event. However, upon receiving a sensorStart event, the Cortex R4 disconnects in CCS. The error log for it is below:

IcePick_M_0: Error: (Error -261 @ 0xFFFFFEFB) Invalid response was received from the XDS110. (Emulation package 7.0.48.0)
CS_DAP_0: Error: (Error -261 @ 0x0) Invalid response was received from the XDS110. (Emulation package 7.0.48.0)
Cortex_R4_0: Error: (Error -261 @ 0x0) Invalid response was received from the XDS110. (Emulation package 7.0.48.0)
CS_DAP_0: Unable to determine target status after 20 attempts
CS_DAP_0: Failed to remove the debug state from the target before disconnecting. There may still be breakpoint op-codes embedded in program memory. It is recommended that you reset the emulator before you connect and reload your program before you continue debugging
Cortex_R4_0: Unable to determine target status after 20 attempts
Cortex_R4_0: Failed to remove the debug state from the target before disconnecting. There may still be breakpoint op-codes embedded in program memory. It is recommended that you reset the emulator before you connect and reload your program before you continue debugging

I've tested with multiple different radars, and the same issue occurs with each of them. 

Any help is much appreciated! 

[unlocked 1/24/18]>LE

  • 0
    TI__Mastermind 21025 points

    HI David,

    Are you loading the demo program onto both cores (R4F and DSP) and starting them both?  It sounds as if the DSP isn't running.  When you issue the sensorStart command, the R4 sends mailbox events to the DSP to transfer the configuration parameters.  It will assert if the DSP isn't running.

     -dave

  • 0 in reply to db_woodall
    Prodigy 120 points

    Hi Dave,

    They're both started up and running. I've attached an image to show what it looks like post-sensorStart.

    Thanks!

  • 0 in reply to David Murdoch
    TI__Mastermind 21025 points
    Hmm. Are you running one of the default profile configs? If you stop both cores, where are they? If its on an assert on the ARM, the call stack should show where it happened. You may be able to glean some information from gMmwMssMCB and gMmwDssMCB - in terms of what configuration structures have been loaded and what the stats show.
  • 0 in reply to db_woodall
    Prodigy 120 points
    I am on a default profile, yes.
    Part of the problem is that I can't stop or check anything on the cores. It's not an assert on the core or something, the board just disconnects from CCS, and I can't reconnect. CLI logging before the error in my initial post shows that the sensorStart event is received, but then the disconnect occurs and I'm not able to access anything else. Windows also actually plays the USB disconnect sound when the disconnect occurs, but the COM ports for the device are still shown in the device manager after the disconnect.

    Attempting to halt the C674x after sensorstart gives the following error:
    C674X_0: Trouble Halting Target CPU: (Error -2062 @ 0x0) Unable to halt device. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 7.0.48.0) .
  • 0 in reply to David Murdoch
    TI__Mastermind 21025 points
    Strange. Have you tried the mmw demo? Try this:

    Flash: CCS debug image into the iwr1642 using the procedure shown in the SDK user guide, section 3.2.2. Make sure you remove SOP2 jumper when finished.

    Then start the CCS 7.1+ debugger, and load:
    C:\ti\mmwave_sdk_01_01_00_02\packages\ti\demo\xwr16xx\mmw\xwr16xx_mmw_demo_mss.xer4f into the R4f, and
    C:\ti\mmwave_sdk_01_01_00_02\packages\ti\demo\xwr16xx\mmw\xwr16xx_mmw_demo_dss.xe674 into the C674.

    Start both cores, and on the CLI terminal enter the commands from profile_2d.cfg. These are all tested files, and should work. If they don't perhaps try another PC or try rebooting.
  • 0 in reply to db_woodall
    Prodigy 120 points

    Same problem occurs, but the CLI appears to remain functional in TeraTerm. I can send sensorStop commands and receive an acknowledgement. 

    I've tried rebooting and that did not fix the problem. I've also tried both a modified version and a clean version of the automotive demo for TIDEP-9000, and the same result occurs. Using a different PC, the problem disappears, but that's not really a long term solution for me unfortunately.

    The issue reproduces across different AWR1642 radars and different demoes, but only on my PC; other PCs have no problem running these demos, so it has to be something particular that's gone wrong with my setup. A fresh install of the mmwave sdk hasn't fixed the problem. I'm going to go ahead and re-install CCS as well, and see if that fixes the problem. 

  • 0 in reply to David Murdoch
    Prodigy 120 points
    CCS reinstall did not fix the issue.
  • 0 in reply to David Murdoch
    TI__Mastermind 21025 points
    It's good to hear that you can get it to work on other PCs - that means you're not doing something wrong. Perhaps there's an issue with your USB drivers - maybe try updating them or going through a hub might help? You could also try creating a new CCS target configuration.
  • 0 in reply to db_woodall
    Prodigy 120 points

    The USB drivers on this PC are all up to date. I tried a new CCS configuration as well, but no luck unfortunately.