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.

IWR1443: Meaning of mmWave Control failed [Error code -203227134]

Part Number: IWR1443
Other Parts Discussed in Thread: TIDEP-0091

I am trying to set up the IWR1443 high-accuracy lab to be a stand-alone firmware without the need for the visualizer to start the scanning.  To do so, I am modifying the code so that the CLI functions are not used and are instead replaced with functions that perform the same sequence of setup steps as in the level_sense_demo lab [demo_staticConfig() in demo.c].  When I run the code and the MMWave_config() function is called, an error message appears as shown in the title of this thread.  How do I determine what that error message means and how to resolve the error?

  • Hi Alan,

    I've asked an expert to look into this and we should have an answer for you in the next few days.

     

    Cheers,

    Akash

  • Hi Akash,

    I have noticed that the gMmwMCB definition is different between the level sense demo and the high accuracy lab.  Perhaps that's part of the issue here.  By repeated changing of how the errCode values are set and recompiling of the ti\control module, I found that the dfeDataOutputModel had not yet been set when the MMWave_config() function was called.  I explicitly set that variable, only to run into a different error.  That error was traced to the rlSetProfileConfig() function in rl_sensor.c.  I have not been able to determine the exact cause of that error.

    I have also tried creating a set of functions that duplicate what the CLI does when a configuration file is sent from the High-Accuracy Visualizer.  That also resulted in the same kind of error when the MMWave_config() function was called.

    Perhaps we are going about this in a manner that is more complicated than necessary.  Essentially, what we need is for the device to configure itself upon bootup using a statically-defined configuration, and then perform a radar scan before being shut down.  We want to remove the CLI operation entirely from the firmware.  Hence the thought to put the operations of the demo_staticConfig function into the high-accuracy lab firmware.

    Perhaps it would be simpler to start with the level_sense_demo lab and modify it to produce a high-accuracy scan.  The fact that the mwMCB definition is different between two labs makes it difficult to determine what is actually required for a basic level sensing functionality versus a high-accuracy version.

    Could you (or someone) explain the configuration differences that make the IWR1443 create a high-accuracy scan as opposed to a 'regular' accuracy scan?  Does it consist of a few configuration changes, or are the two types of scans mutually exclusive and require very different configuration settings and structures?

    Best regards,

    Alan

  • Hi Akash,

    I have continued to work on adapting the high-accuracy lab to not require the CLI functions.  I have been able to replace all but one of the functions called by the High-Accuracy Visualizer with my own functions and have the chip start up and make measurements.  The issue is replacing the CLI_MMWaveProfileCfg() function in cli_mmwave.c.  I created my own version of that function and verified that it sets up the profileCfg structure with exactly the same values as the CLI version.  I can get it to be successfully added as a profile using the MMWave_addProfile() function.  However, when I try to run the firmware, I get different error messages depending on whether or not I invoke the CLI version and/or my version.

    If I have just the CLI profile configuration function run, the device runs normally when started through the High-Accuracy Visualizer.

    If I have both profile configuration functions run, I get "Error: mmWave Control failed [Error code -203685722]" when I start the device through the High-Accuracy Visualizer.

    If I have just my version of the function run, I get "Error: mmWave Control failed [Error code -203227134]" when I start the device through the High-Accuracy Visualizer.

    If I have both profile configuration functions run, but call the MMWave_delProfile() function to delete the profile added by the CLI function, I get "Error: mmWave Control failed [Error code -203685722]" when I start the device through the High-Accuracy Visualizer.  I find that the MMWave_delProfile() function returns a -203227134 for the errCode argument.

    It's pretty difficult to troubleshoot the issue when the error messages are cryptic and the code that generates them is in a library, so I cannot step through that code using the IDE.

    Is there some way for me to determine what these error codes mean?  Also, since deleting and then adding what appears to be the same profile creates a non-working configuration, is there some description of how to create/add/delete profiles that might indicate what is going wrong?

    Best regards,

    Alan

  • Hi Alan,

    Apologies for the delay, are you still having issues here?

    Cheers,

    Akash

  • Hi Akash,

    I eventually found that the issue was with the setting of the profileCfg->startFreqConst variable in the CLI_MMWaveProfileCfg() function.  The lack of explicit casting and parentheses to specify the order of operations in calculating that variable.  Once I set up explicit casting and parentheses, I got the same resultant number in my function as in the CLI function.  With the correct number for that variable, the system runs and takes measurements.

    Unfortunately, I still have the problem that the High-Accuracy lab runs the calibration at startup.  That consumes a lot of power.  Have not found a way to stop the full calibration from running.  From looking at the level sense demo lab, it appears that the calibration doesn't run if valid calibration data can be read from flash.  Is that the case?  If so, will pursue that approach.  Am also trying to splice in the second FFT from the High Accuracy lab into the level sense demo.

    Best regards,

    Alan

  • Hi Alan,

    That sounds good.

    Keep in mind that in the TIDEP-0091, it will run a calibration and store the data only if you tell it to. Otherwise it will run a measurement with a full-calibration.

    Cheers,

    Akash

  • Hi Akash,

    Understood.  I forced the demo_mode variable to be for calibration, ran the code once, then changed the demo_mode to be for measurement, and then ran the code again.  I was able to see the difference in power draw on the oscilloscope and verify that the device was taking a measurement.

    Best regards,

    Alan