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

Original question:

IWRL6432: Cannot send radar config to device when in debug mode. mmWaveErrorCode -3101 and subsysErrorCode 0

IWRL6432: The hard coded radar config in mmw_cli.c has different behavior from loading the same config via the visualizer.

Daniel Sharp
Prodigy 160 points
Part Number: IWRL6432

I would like to use the hard coded config in the mmw_cli.c file in the motion and presence demo.

I get the following error when trying to use this config. 

Error: mmWave Control Initialization failed [Error code -203227134] [errorLevel 2] [mmWaveErrorCode -3101] [subsysErrorCode 0]
Exception: ../motion_detect.c, line 2522.

When inspecting the code, I have found that the gMmwMssMCB.ctrlHandle never gets set. This is checked inside of the factory config functions and ultimately results in the error. 

I am using the exact same configuration as the motion demo config, which works when configuring through the visualizer. 

Can you please help me identify why using the hard coded config would result in an error in the factory calibration functions?

I have gone through the following efforts in trying to debug this problem:

- stepped through the code to verify that the config commands are valid, they are

- modified the factoryCalibCfg command parameters to point to the ATE calibration location manually

- identified that SOC_XWRL64XX doesn't appear to be defined anywhere 

- create a debug build and a release build, neither works

Thank you in advance. 

This is an image of the radarCmdString I am using. 

  • 0
    TI__Mastermind 20451 points

    Hi, 

    I have some Questions to help me better understand your situation:

    1. What is the mmWave L SDK version which is being used?
    2. Are you experiencing this error after flashing the generated .appimage file to the device and running in functional mode? Or is this error seen when loading the .out file through CCS and running in debug mode? Or is this error seen in both instances?
    3. Are there any additional changes you have made to the code other than enabling CLI_BYPASS and updating the radarCmdString as shown in the image?

    Daniel Sharp said:
    identified that SOC_XWRL64XX doesn't appear to be defined anywhere

    SOC_XWRL64XX is a predefined symbol. It is defined in the makefile, or in the .projectspec file if using CCS to build.

    Best Regards,

    Josh

  • 0 in reply to Josh Dye
    Prodigy 160 points

    Hi Josh, 

    Thanks for reaching out. I seem to have resolved most of this issue. I found that one of my print statements was putting the board into a reset state that would cause this error when disconnecting from the core, reconnecting, and loading the code. To solve this state, I had to power cycle the board a few times. 

    Removing the printf() statement fixed the problem moving forward. Further work showed that a breakpoint can also cause the board to enter this reset state. For others looking at this problem I will still answer the questions you asked. 

    1. I am using  MMWAVE_L_SDK_05_01_00_04

    2. This error happens when in debug mode. When using an unmodified demo I was able to solve the problem, meaning my code additions were the problem. 

    3. Yes there were, these caused the problem. 

    One part of the problem that I have not resolved is this error. 

    Cortex_M4_0: JTAG Communication Error: (Error -1170 @ 0x0) Unable to access the DAP. 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 9.7.0.00213)
    Cortex_M4_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 receive this error whenever I hit "resume" and the board gets going. This happens whether or not I am connected to the visualizer. The visualizer continues to show detections, but when trying to inspect the outgoing data values through CLI_write() commands it appears that all the data is 0. Do you have any thoughts on this error? 

  • 0 in reply to Daniel Sharp
    TI__Mastermind 20451 points

    Hello, 

    Glad you were able to resolve your issue. Thank you for providing the details of the issue and resolution. 

    This error that you are seeing is likely due to low power modes being enabled in your configuration. With low power modes enabled the device enters deep sleep mode after it completes processing for a frame, this causes the JTAG connection to be dropped and results in the error you are seeing. The demo should continue to run on the device however, and continue to output data over UART. This is why the visualizer continues to show the detected objects. For debugging in CCS, you should use 'lowPowerCfg 0' This way, the device will not enter the deep sleep mode and the JTAG connection will not be dropped.

    Daniel Sharp said:
    when trying to inspect the outgoing data values through CLI_write() commands it appears that all the data is 0.

    This is peculiar and I am not quite sure what would cause this. Where are you calling the CLI_write function and what data are you trying to display?

    Daniel Sharp said:
    Further work showed that a breakpoint can also cause the board to enter this reset state.

    There is a global variable 'gDebugTargetCode' which must be set to 1 to use breakpoints, step through code, etc.... Without this global variable set, mmwDemoFrameStartISR will force the code to stop. You can either set the variable to 1 in the code and rebuild the project or you can set it using the Expressions window in CCS before hitting 'resume'.

    Best Regards,

    Josh

  • 0 in reply to Josh Dye
    Prodigy 160 points

    This is incredible information thank you Josh. I will mark my issue as resolved.

    I was able to figure out why the CLI_write() was printing zeros for the detection list. The problem is when using the terminal to view point cloud data, naturally the COM port is being used, so I was not using the visualizer. In the process of connecting to the visualizer a variable gets set pGuiMonSel->pointCloud. When only viewing point cloud data through the terminal the pointCloud value was 0, and when viewing it through the visualizer it was 1. So, in order to view point cloud data via a CLI_write() command to the terminal you must manually set the pGuiMonSel->pointCloud = 1. 

  • 0 in reply to Daniel Sharp
    TI__Mastermind 20451 points

    Hi, 

    That is good to hear that your issue is resolved. If you have any additional questions, please don't hesitate to create a new post.

    Best Regards,

    Josh