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.

IWR6843AOP: Debugging Causes Crash and Other Critical XDS110 Bugs

Part Number: IWR6843AOP
Other Parts Discussed in Thread: MMWAVEICBOOST, ,

I'm having an issue where I cannot use CCS to debug my program. When the debugger is used, the software will crash every time. However, the exact same program when uploaded through the bootloader and loaded from the local QSPI flash works perfectly fine. This would seem to indicate that something is fundamentally wrong with how the debugger interacts with the chip.

[Cortex_R4_0] **********************************************
Debug: Launching the MMW Demo on MSS
**********************************************
Debug: Launched the Initialization Task
Debug: mmWave Control Initialization was successful
Debug: mmWave Control Synchronization was successful
Debug: CLI is operational
[C674X_0] Debug: DPM Module Sync is done
[Cortex_R4_0] Debug: Sending rlRfSetLdoBypassConfig with 0 0 0
{module#9}: "C:/TI/mmwave_industrial_toolbox_4_5_1/labs/automated_doors_and_gates/68xx_automated_doors/src/mss/mss_main.c", line 2431: error {id:0x10000, args:[0x237fc, 0x237fc]}
xdc.runtime.Error.raise: terminating execution

Which is thrown by:

static int32_t MmwDemo_eventCallbackFxn(uint16_t msgId, uint16_t sbId, uint16_t sbLen, uint8_t *payload)
{
    uint16_t asyncSB = RL_GET_SBID_FROM_UNIQ_SBID(sbId);

    /* Process the received message: */
    switch (msgId)
    {
        case RL_RF_ASYNC_EVENT_MSG:
        {
            /* Received Asychronous Message: */
            switch (asyncSB)
            {
                case RL_RF_AE_CPUFAULT_SB:
                {
                    MmwDemo_debugAssert(0);
                    break;
                }

This behavior also changes to a complete lockup at this point unless the chip is reset via hardware for subsequent debug sessions. This may be an issue on our part for hooking up the JTAG port, but I'll include the schematic to show you what we did. We are using the TI 20-pin to ARM Cortex 10-pin converter included with the XDS110. (If possible, I'd like to get a schematic for that adapter.)

[C674X_0] Debug: DPM Module Sync is done
[Cortex_R4_0] **********************************************
Debug: Launching the MMW Demo on MSS
**********************************************
Debug: Launched the Initialization Task

The debugger also has this bizarre behavior where if the target is disconnected or loses power while debugging, I not only have to unplug the XDS110 from my computer, but I also have to restart CCS in order to get debugging to work at all. When reconnecting power and trying again immediately after failure, this error occurs:

Then if the XDS110 is reconnected, you get this error:

Which won't go away until CCS is completely restarted.

  • Hello

    My previous response did not show up so redoing it.

    Can you please confirm if the  CCS debug issue is seen with the CCS debug image flashed on to the device.

    Thank you,

    Vaibhav

  • Using "C:\TI\mmwave_sdk_03_05_00_04\packages\ti\utils\ccsdebug\xwr68xx_ccsdebug.bin" did not make a difference. Same error. And frankly, I'm confused about why you would need to use a special binary in order to use the debugger? No other microcontroller on the market seems to need such a thing as their debug systems are fully capable of resetting the device into a known, valid state. 

  • Abram:

    All IWR devices require the ccs debug binary to be flashed to the device as is specified in the user guide for each demo that  is provided. Are you using a stand alone XDS110 Debug Probe or are you using a MMWAVEICBOOST with your setup?

    Best regards,

    Connor Desmond

  • As vaguely mentioned in my original post, we broke out the JTAG interface on our custom board and are using a XDS110 debug probe directly through that port. 

  • Hello

    Can you please confirm the following

    1. Are you able to see similar issue on TI  EVM  or is this issue seen only on the custom board implementation.  or in other words are you able to reproduce this issue on TI's EVM as it will help us understand if it is a HW implementation vs SW/Debug image issue.

    2.  Do you see similar issue  on TI's EMV   for  scenario : 

    Flashed image: ccs debug image was tried,

    Load via Jitag to device memory .xe* files  for demos provided by TI  .

    Once the above issues are looked at we can go into  Power reset behavior of CCS-jtag.

    Thank you,

    Vaibhav

  • Apologies for the radio silence, I've been rather ill for a good while. So, correction: After PROPERLY installing the debug image, I was able to debug my application on our custom board. I messed up the upload process when I checked this earlier.

    That aside, the chip must still be reset directly from the host controller on our board before I can run debug again. This may be due to how reset is asserted, but the host uses open-drain to assert reset so the debugger should still be able to cause a reset. It may also be how the reset signal is attached when using the TI 20-pin to ARM Cortex 10-pin converter included with the XDS110. (Which I would still appreciate a schematic for.)

    The rest of the post regarding the XDS110 bugs due to target reset/power loss while connected is still an issue.

  • Abram:

    We are in the process of looking the behavior you are describing. When I touch base with the relevant experts I will respond back.

    Best regards,

    Connor Desmond

  • Abram:

    With regards to power cycling or disconnecting from target while debugging I connected one of our EVMs, IWR6843AOP, ran the OOB demo. To start a another debug session you have to issue a CPU reset, then reload the binary to start another debug session. Otherwise you need to stop the current debug session, press NRST switch on the device, launch the configuration file, connect to target, load binary, and run. Can you try these steps on with your setup? Also do you have an evaluation board?

    Best regards,

    Connor

  • This is the only CPU reset I can find within CCS during debugging. It seems like it just does a "soft" reset since it just immediately runs the binary I had loaded and crashes. It does not appear to run the debug binary, which as I understand it, MUST be run before starting any debugging session.

    Is the XDS110 capable of asserting NRESET on the JTAG connector? Is there a setting to enable that?

    That said, this doesn't fix the issue. If power to the board is lost OR the chip is reset whilst CCS is connected to the debugger/IWR6843AOP in an active session, CCS MUST be restarted, and the XDS110 MUST be disconnected and reconnected to the computer. I can't even start a new debugging session. The issue isn't that I don't know how to avoid this since I just need to stop the debug session before hitting reset, as you mentioned. Are you not seeing this behavior?

    The only board at my disposal is the IWR6843AOPEVM.

  • Abram:

    The behavior described above is with the MMWAVEICBOOST EVM. Since I can not reproduce the behavior that you are sharing can you please compare your XDS110 setup to the XDS110 implementation on the MMWAVEICBOOST EVM. Below you can find the schematic and other technical documents.

    MMWAVEICBOOST Homepage:
    www.ti.com/.../MMWAVEICBOOST

    Best regards,

    Connor Desmond

  • I can't find any meaningful difference between the two, and I've discovered that a watchdog warm reset triggers the same behavior. What else can I provide?

    CCS: 10.3.1.00003 

    XDS110 + Library

    This utility has selected a 100- or 510-class product.
    This utility will load the adapter 'jioxds110.dll'.
    The library build date was 'Apr 29 2021'.
    The library build time was '17:49:40'.
    The library package version is '9.3.0.00058'.
    The library component version is '35.35.0.0'.
    The controller does not use a programmable FPGA.
    The controller has a version number of '5' (0x00000005).
    The controller has an insertion length of '0' (0x00000000).
    This utility will attempt to reset the controller.
    This utility has successfully reset the controller.

    Device Configuration

    <?xml version="1.0" encoding="UTF-8" standalone="no"?>
    <configurations XML_version="1.2" id="configurations_0">
    <configuration XML_version="1.2" id="Texas Instruments XDS110 USB Debug Probe_0">
            <instance XML_version="1.2" desc="Texas Instruments XDS110 USB Debug Probe_0" href="connections/TIXDS110_Connection.xml" id="Texas Instruments XDS110 USB Debug Probe_0" xml="TIXDS110_Connection.xml" xmlpath="connections"/>
            <connection XML_version="1.2" id="Texas Instruments XDS110 USB Debug Probe_0">
                <instance XML_version="1.2" href="drivers/tixds510debugssm.xml" id="drivers" xml="tixds510debugssm.xml" xmlpath="drivers"/>
                <instance XML_version="1.2" href="drivers/tixds510cs_dap.xml" id="drivers" xml="tixds510cs_dap.xml" xmlpath="drivers"/>
                <instance XML_version="1.2" href="drivers/tixds510cortexR.xml" id="drivers" xml="tixds510cortexR.xml" xmlpath="drivers"/>
                <instance XML_version="1.2" href="drivers/tixds510cs_child.xml" id="drivers" xml="tixds510cs_child.xml" xmlpath="drivers"/>
                <instance XML_version="1.2" href="drivers/tixds510etbcs.xml" id="drivers" xml="tixds510etbcs.xml" xmlpath="drivers"/>
                <instance XML_version="1.2" href="drivers/tixds510icepick_m.xml" id="drivers" xml="tixds510icepick_m.xml" xmlpath="drivers"/>
                <instance XML_version="1.2" href="drivers/tixds510c674x.xml" id="drivers" xml="tixds510c674x.xml" xmlpath="drivers"/>
                <platform XML_version="1.2" id="platform_0">
                    <instance XML_version="1.2" desc="IWR6843AOP_0" href="devices/iwr6843AOP.xml" id="IWR6843AOP_0" xml="iwr6843AOP.xml" xmlpath="devices"/>
                </platform>
            </connection>
        </configuration>
    </configurations>

  • Abram:

    I am going to have to get back you next week on this.

    Best,

    Connor Desmond

  • At this point, please consider this thread to be a low priority bug report. It is not actively impeding my progress now that I've gotten used to the procedure.

  • Abram:

    I have reached out to an expert on this, but if you are used to the procedure and don't want to continue the thread then please resolve, but if you want me to keep this thread on my radar then I will keep this open.

    Best regards,

    Connor Desmond