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.

IWR6843ISK: FCC Certification using mmWave SDK in CW mode...

Part Number: IWR6843ISK
Other Parts Discussed in Thread: DCA1000EVM, UNIFLASH

We're using SDK 3.4.0.3.  We've added commands to cli_mmwave.c to allow for a configuration of 'dfeDataOutputMode 2' and 'contModeCfg 60.25, 0, 0, 10000, 0, 131072, 30, 0, 256'.

We're getting ready to take the product to an FCC testing house and we can only use the IWR6843ISK to run the tests with.  We have configurations for the chirp testing that we think will work without using LUA commands, but we need something similar for the continuous wave tests.

The code for contModeCfg is as follows:

static int32_t CLI_MMWaveContModeCfg (int32_t argc, char* argv[])
{
MMWave_ContModeCfg *contCfg = &gCLIMMWaveControlCfg.u.continuousModeCfg;

/* Sanity Check: Minimum argument check */
if (argc != 10)
{
CLI_write ("Error: Invalid usage of the CLI command\n");
return -1;
}

/* Sanity Check: Continuous configuration is valid only for the Continuous Mode: */
if (gCLIMMWaveControlCfg.dfeDataOutputMode != MMWave_DFEDataOutputMode_CONTINUOUS)
{
CLI_write ("Error: Configuration is valid only if the DFE Output Mode is Continuous\n");
return -1;
}

/* Populate the configuration: */
contCfg->cfg.startFreqConst = (uint32_t) (atof(argv[1]) * (1U << 26) /
gCLI_mmwave_freq_scale_factor);
contCfg->cfg.txOutPowerBackoffCode = (uint32_t) atoi (argv[2]);
contCfg->cfg.txPhaseShifter = (uint32_t) atoi (argv[3]);
contCfg->cfg.digOutSampleRate = (uint16_t) atoi (argv[4]);
contCfg->cfg.hpfCornerFreq1 = (uint8_t) atoi (argv[5]);
contCfg->cfg.hpfCornerFreq2 = (uint8_t) atoi (argv[6]);
contCfg->cfg.rxGain = (uint16_t) atoi (argv[7]);
/*argv[8] is reserved*/
contCfg->dataTransSize = (uint16_t) atoi (argv[9]);
return 0;
}

All of this appears to configure correctly.  However, it's difficult to tell if the unit is actually running in CW mode when we send sensorStart on this configuration.  This isn't really a typical data-path configuration, so we're not sure what to expect.  Is there anything else we need to setup beforehand?  Is there any way to confirm that this is working (or not)?  If it runs, will it only run for the 256 cycles and then stop?

-Tom Grounds

  • Hi Tom,

    I will be getting back to you in the next 2 hours on this topic.

    Thank you,

    Angie

  • Hi Tom,

    Are you using our Studio CLI tool: here?

    This tool can be used to enable CW mode over CLI.

    Thanks,

    Angie

  • Let me take a look.

  • This mmwavestudio CLI tool looks like it uses the DCA1000EVM and/or the BOOST for setup of the CLI commands.  While this is helpful, we are trying to setup the CW mode using only the IWR6843ISK connected to a small computer board (without the DCA/BOOST) for the test, so I'm not sure we can use this for the CW mode setup.  Let me know if that's incorrect.

  • Hi Thomas,

    Thank you for explaining! Why are you only able to use the IWR6843ISK board for testing?

    There is a continuous mode API which can be accessed by calling (rlEnableContMode , rlSetContModeConfig). See documentation here <sdk_download_location>/mmwave_sdk_03_06_00_00-LTS/packages/ti/control/mmwave/docs/doxygen/html/struct_m_m_wave___cont_mode_cfg__t.html

    For raw ADC data capture the DCA1000 is required, which is why it is needed for the mmwavestudio and mmwavestudio cli tools.

    Thanks,

    Angie 

  • Thanks for getting back to me.  My understanding is that only the field equipment that will be in the unit can be present at the FCC test.  That's why they want this to be done using just the IWR6843ISK board, the code we've developed for it and the underlying SDK.  So we're trying to build in the CW test into the system.  I have seen the referenced html file for the rlContModeCfg_t in the related link you provided: MMWave_ContModeCfg_t Struct Reference which only appears to hold the number of samples per channel.  There is no additional information about how to actually start the sensor for the CW mode.  Do you have an example of the setting of the structure, and the call to rlEnableContMode or rlSetContModeConfig through the SDK that we can look at?  We thought these calls would be made using the 'dfeDataOutputMode 2' and 'contModeCfg 60.25, 0, 0, 10000, 0, 131072, 30, 0, 256' commands, followed by the sensorStart command through the CLI.  Any idea what we should expect to see from the data-path (if anything), or if the CW mode runs until we stop it or for just a short period of time?  There doesn't seem to be much information about how to do this through the SDK, and the FCC testing is pretty critical to the product release.

  • Hi Thomas,

    I want to make sure you have found our document on Regulatory Compliance. Figure 4-1 shows our recommended minimum set up for testing and section 5.5.1 discusses CW mode but shows that the DCA1000 is needed for this. The DCA1000 is an evaluation board and is what we see people use to generate the CW test.

    Since we have mmwavestudio and the mmwave studio cli tools for running in CW mode we do not have any examples for accessing the CW API directly.

    The best way to verify if your 'contModeCfg 60.25, 0, 0, 10000, 0, 131072, 30, 0, 256' would be to set up the device is to test it in mmwave studio to see what responses you are seeing. 

    Thank you,

    Angie

  • Hello Angie,

    Yes, we've reviewed the Regulatory Compliance document.  However, we cannot fit the boost board and the DCA1000 into the product we're trying to have tested, and we feel there should be a way to run CW for the test with only the IWR6843ISK board.

    We've been developing locally on a Windows 10 system using Code Composer, but it looks like the mmwave studio cli requires development on the cloud.  Is that correct?  Can the mmwave studio cli interface to the IWR6843ISK be used to generate CW signals without the Boost/DCA1000, or are those tools still required for CW for the target board?

  • We're not looking to do a capture in the above proposed CLI configuration, we can do that with our mmWave Studio setup.  I'm just trying to find a way to get the device reliably into CW mode with just the target board interfaced to a computer system - if we have the target board loaded with the right firmware.

  • Hi Thomas, 

    Sorry for the delay here, I appreciate your patience. 

    I was able to find this link test file that may help you verify that the API is working, you can find the source code at: <SDK_DOWNLOAD_LOCATION>\mmwave_sdk_03_06_00_00-LTS\packages\ti\control\mmwavelink\test\common\link_test.c. This is all we seem to have on this subject. 

    Thank you,

    Angie 

  • I will take a look.  Thanks.  -TomG.

  • Thanks Tom! Please let me know if you have any more questions.

    Angie

  • Angie,

    We're trying to setup a development project using Code Composer Studio 12.1.0.00007 where we can try to import some of the features of the link_test.c into, to work on getting a CW test operating while maintaining some desired features for our target product.  However, we can't seem to get the project to actually run or debug properly from the industrial toolbox (4.12.0) Long_Range_People_Detection for the 6843 with regard to running the datapath after using the standard configuration.  I've setup a separate query here: IWR6843ISK: Issues compiling a working Long Range People Detection project... - Sensors forum - Sensors - TI E2E support forums  If you or someone else on your team could work with us to get this going, we'll try to use that to get some of the code from the link_test.c integrated.

  • Hi Thomas,

    My co-worker will be looking into that ticket and assisting you shortly. I have given him the background on what you are working on. 

    Thank you,

    Angie

  • Thanks Angie.  I hope to hear from them soon.  I'm continuing to work on the project while I wait for their suggestions: I've integrated the link_test code into the project setup for the mmwave_industrial_toolbox_4_12_0 Long_Range_People_Detection 6843.  At the end of the MmwDemo_initTask where the CLI is finished being initialized, I inserted this code from the link_test project:

    MmwDemo_CLIInit(MMWDEMO_CLI_TASK_PRIORITY);

    //System_printf ("Debug: CLI initialized\n");

    // Setup mmwavelink interface TLG
    MmwaveLink_initLink(RL_AR_DEVICETYPE_68XX, RL_PLATFORM_MSS); //placement here at the end of the initialization seems to work. TLG

    // Force CW TLG
    if (MmwaveLink_setContModeConfig() < 0) {
    System_printf ("Debug: MmwaveLink_setContModeConfig completed\n"); //set to 60GHz CW
    }

    if (MmwaveLink_enableContMode(1) < 0) {
    System_printf ("Debug: MmwaveLink_enableContMode completed\n"); //enable CW
    }

    if (MmwaveLink_sensorStart() < 0) { //
    System_printf ("Debug: MmwaveLink_sensorStart completed\n");
    }

    Task_sleep(10000);

    if (MmwaveLink_sensorStop() < 0) { //
    System_printf ("Debug: MmwaveLink_sensorStop completed\n");
    }

    System_printf ("Debug: MmwaveLink CW test completed\n");

    for the ContModeCfg settings I'm using:

    //found in link_testcase_config.c TLG
    //sets the CW output to 60GHz
    const rlContModeCfg_t contModeCfg =
    {
    .startFreqConst = 1497521874,
    .txOutPowerBackoffCode = 0,
    .txPhaseShifter = 0,
    .digOutSampleRate = 10000,
    .hpfCornerFreq1 = 0,
    .hpfCornerFreq2 = 0,
    .rxGain = 30,
    .vcoSelect = 0x0,
    .reserved = 0x0
    };

    When I run this code on the emulator during debug, I get the following:

    [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: MmWave CTL Task priority set
    Debug: DPC init configured
    Debug: DPC call-back configured
    Debug: DPM Module initialized
    Error: DPM Synchronization timed out
    Debug: DPM sync completed
    Debug: dpm task launched
    Debug: Cycleprofiler Initialized
    Debug: CLI is operational
    Debug: CRC Channel @08006db8 has been opened successfully
    Debug: Launched the mmwaveLink Management Task
    Debug: BSS Mailbox Handle @08001d78
    Debug: Disabling the device
    Debug: BSS Mailbox Handle @08001d78
    Debug: Power on request successfully passed to the BSS
    Debug: Finished rlSetContModeConfig
    Debug: Finished rlEnableContMode
    Error: Unable to start Sensor [Error 22]
    Debug: MmwaveLink_sensorStart completed
    Debug: Frames are already stopped [21]
    Debug: MmwaveLink CW test completed

    So, it looks like it would not start the sensor at this point without a full configuration (?) - which I then use the CLI to provide, pasting each individual setting in to the Terminal.  At the end of the CLI configuration entry I use our contModeCfg CLI command to try and enter the CW configuration:

    ...

    mmwDemo:/>bpmCfg -1 0 0 0
    Done
    mmwDemo:/>dfeDataOutputMode 2
    Done
    mmwDemo:/>contModeCfg 60.25, 0, 0, 10000, 0, 131072, 30, 0, 256
    Done
    mmwDemo:/>sensorStart 0 0

    and then start the sensor to which I get:

    Error: Unable to start Sensor [Error 22]

    Same issue as when I tried to force the CW mode after initialization.  So maybe the issue is not with the full configuration.  I can't seem to find a reference to what Error 22 is in this context.

    If I then try to use the sensorStart CLI command I get:

    Debug: Sending rlRfSetLdoBypassConfig with 3 1 0
    Debug: CPU Fault has been detected
    Debug: Fault
    type: 3, lineNum: 1261, LR: 0x29ec2
    PrevLR: 0x0, spsr: 0x6000011f, sp: 0x800fb50, PC: 0x0
    Status: 0xffff, Source: 255, AxiErrType: 255, AccType: 255, Recovery Type: 255
    Debug: ESM Fault. Group1:[0x0] Group2:[0x0]
    Debug: Analog Fault Async Event

    So, that final setting attempt doesn't work either, and it causes a CPU fault as well.

    Any suggestions would be appreciated.

    -TomG.

  • Hi Tom,

    The CLI Init task initializes the CLI but does not assign the values to the CLI. I would try running the link test after the values have been sent over CLI and see if you get the same error.

    Thanks,

    Angie

  • OK, we will give that a try.  I'm waiting for a response back on the other thread to make sure that the DSS is running during our test of the MSS software.  The MSS can communicate to the BSS for the Mmwave_link interface but it's unclear if the DSS is actually running on the debugger as it should since the two do not 'sync' yet on the debug system (XDS110 Debug Probe).  Once I hear back from them, I should be able to try your suggestion.

  • Hi Thomas,

    Sounds good, I'll keep in touch with Josh in here at our TI office as well.

    Thank you,

    Angie

  • Angie, I was able to resolve my issue, making sure that the DSS is running during the debugging process on the target board.  So I'm back to trying to get the overall sample project to run.  I'm running up to the point where the CLI is established, and then I'm configuring it with the 6843_50m_3D.cfg file by hand:

    ******************************************
    xWR68xx MMW Demo 03.05.00.04
    ******************************************
    mmwDemo:/>sensorStop
    Ignored: Sensor is already stopped
    Done
    mmwDemo:/>flushCfg
    Done
    mmwDemo:/>dfeDataOutputMode 1
    Done
    mmwDemo:/>channelCfg 15 7 0
    Done
    mmwDemo:/>adcCfg 2 1
    Done
    mmwDemo:/>adcbufCfg -1 0 1 1 1
    Done
    mmwDemo:/>profileCfg 0 60 35 6 43.0 0 0 8.241 1 125 3433 0 0 48
    Done
    mmwDemo:/>chirpCfg 0 0 0 0 0 0 0 1
    Done
    mmwDemo:/>chirpCfg 1 1 0 0 0 0 0 4
    Done
    mmwDemo:/>chirpCfg 2 2 0 0 0 0 0 2
    Done
    mmwDemo:/>frameCfg 0 2 96 0 100 1 0
    Done
    mmwDemo:/>lowPower 0 0
    Done
    mmwDemo:/>guiMonitor -1 1 0 0 0 0 0
    Done
    mmwDemo:/>cfarCfg -1 0 2 8 4 3 0 10 0
    Done
    mmwDemo:/>cfarCfg -1 1 0 4 2 3 1 10 0
    Done
    mmwDemo:/>multiObjBeamForming -1 1 0.5
    Done
    mmwDemo:/>clutterRemoval -1 1
    Done
    mmwDemo:/>calibDcRangeSig -1 0 -5 8 256
    Done
    mmwDemo:/>extendedMaxVelocity -1 0
    Done
    mmwDemo:/>bpmCfg -1 0 0 1
    Done
    mmwDemo:/>lvdsStreamCfg -1 0 0 0
    Done
    mmwDemo:/>compRangeBiasAndRxChanPhase 0.0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0
    Done
    mmwDemo:/>measureRangeBiasAndRxChanPhase 0 1.5 0.2
    Done
    mmwDemo:/>CQRxSatMonitor 0 3 4 63 0
    Done
    mmwDemo:/>CQSigImgMonitor 0 127 4
    Done
    mmwDemo:/>analogMonitor 0 0
    Done
    mmwDemo:/>aoaFovCfg -1 -90 90 -90 90
    Done
    mmwDemo:/>cfarFovCfg -1 0 0 59.99
    Done
    mmwDemo:/>cfarFovCfg -1 1 -30 30.00
    Done
    mmwDemo:/>staticBoundaryBox -50 50 0.5 60 -0.5 6
    Done
    mmwDemo:/>boundaryBox -50 50 0.5 60 -0.5 6
    Done
    mmwDemo:/>sensorPosition 2 0 0
    Done
    mmwDemo:/>gatingParam 4 6 6 6 10
    Done
    mmwDemo:/>stateParam 4 10 60 600 20 600
    Done
    mmwDemo:/>allocationParam 30 30 0.5 3 2 2
    Done
    mmwDemo:/>maxAcceleration 0.1 0.1 0.1
    Done
    mmwDemo:/>trackingCfg 1 2 250 20 78 121 99
    Done
    mmwDemo:/>presenceBoundaryBox -3 3 2 6 0.5 2.5
    Done
    mmwDemo:/>sensorStart

    The response from the debugger for running the code is:

    [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: MmWave CTL Task priority set
    Debug: DPC init configured
    Debug: DPC call-back configured
    Debug: DPM Module initialized
    Debug: DPM sync completed
    Debug: dpm task launched
    Debug: Cycleprofiler Initialized
    [C674X_0] Debug: DPM Module Sync is done
    [Cortex_R4_0] Debug: CLI is operational
    Debug: Setup MmwaveLink
    Debug: CRC Channel @08006db8 has been opened successfully
    Debug: Launched the mmwaveLink Management Task
    Debug: BSS Mailbox Handle @08001d78
    Debug: for deviceIndex 0
    Debug: Enabling the device 0
    Debug: Disabling the device 0
    Debug: BSS Mailbox Handle @08001d78
    Debug: for deviceIndex 0
    Debug: Enabling the device 0
    Debug: Power on request successfully passed to the BSS
    Debug: MmwaveLink version:
    RF H/W Version : 02.00
    RF F/W Version : 06.03.02.06.20.08.11
    RF F/W Patch Version : 00.00.00.00.00.00.00
    mmWaveLink Version: 01.02.06.06

    (loaded the configuration and running sensorStart at this point)
    Debug: Sending rlRfSetLdoBypassConfig with 3 1 0 [MmwDemo_openSensor]
    Debug: CPU Fault has been detected
    Debug: Fault
    type: 3, lineNum: 1283, LR: 0x2baee
    PrevLR: 0x0, spsr: 0x6000011f, sp: 0x800fb48, PC: 0x0
    Status: 0xffff, Source: 255, AxiErrType: 255, AccType: 255, Recovery Type: 255
    Debug: ESM Fault. Group1:[0x0] Group2:[0x0]
    Debug: Analog Fault Async Event

    The rlRfSetLdoBypassConfig with 3 1 0 output is in MmwDemo_openSensor, which is called in MmwDemo_CLISensorStart.  On my system it's about line 255 in mmw_cli.c. 

    ...

    /* Fill demo's MCB mmWave openCfg structure from the CLI configs*/
    if (gMmwMssMCB.sensorState == MmwDemo_SensorState_INIT)
    {
    /* Get the open configuration: */
    CLI_getMMWaveExtensionOpenConfig (&gMmwMssMCB.cfg.openCfg);
    /* call sensor open */
    retVal = MmwDemo_openSensor(true);
    if(retVal != 0)
    {
    return -1;
    }
    gMmwMssMCB.sensorState = MmwDemo_SensorState_OPENED;
    }
    else
    {...

    So the CPU fault is happening sometime after this point.

    It's not clear why this error is occurring at all, since this is the base project code (long_rang_people_det_6843_mss [industrial tool box 4_12_0]) and we're using one of the recommended configuration files for the project. 

    We're just looking to have some stable code to start from that we can use to integrate the link_text software into for the CW wave configuration and testing.

    -TomG.

  • Hi Tom,

    Is this the code before you integrate the link test software? Are there any other changes you may have made to the code?

    Thank you,

    Angie

  • Angie, Yes, this has the link test software.  I also have some minor changes for the cli_mmwave incorporated (just for an update of the version).  I'm backing out some of the changes to see if I can get to a stable set of code that will run one of the provided .cfg files.  I'll let you know.

  • Angie,

    I started from scratch on a new project, the traffic_monitoring_68xx mss/dss code.  I've added back in the minor changes to the cli and some debug changes that we made to the mss, and then we configured it with the 68xx_traffic_monitoring_70m_MIMO_3D.cfg.  That seems stable.  We get the following:

    [Cortex_R4_0] **********************************************
    Debug: Launching the MMW Demo on MSS
    **********************************************
    Debug: Launched the Initialization Task
    Debug: UART_init completed
    Debug: GPIO_init completed
    Debug: Mailbox_init completed
    Debug: LVDS stream init completed
    Debug: cqSat Config completed
    Debug: UART Logging Setup completed
    Debug: mmWave Control Initialization was successful
    Debug: mmWave Control Synchronization was successful
    Debug: mmWave Control Execution Task setup was successful
    Debug: DPM Module Initialization of L3 CoreRam EDMA and HWA
    Debug: DPM Module Call-backs initialized
    Debug: DPM Module Initialization configuration completed
    Debug: DPM Module Initialization complete
    Debug: DPM Synchronization complete
    Debug: DPM task launched
    Debug: Cycleprofiler Initialized
    [C674X_0] Debug: DPM Module Sync is done
    [Cortex_R4_0] Debug: CLI is operational
    Debug: Sending rlRfSetLdoBypassConfig with 0 0 0
    ============ Heap Memory Stats ============
    Size Used Free DPCUsed
    System Heap(TCMB) 98304 31360 66944 3072
    L3 786176 491520 294656
    localRam(TCMB) 4096 512 3584
    ============ Heap Memory Stats ============
    Size Used Free DPCUsed
    System Heap(L2) 32768 16008 16760 0
    L3 786176 32768 753408
    localRam(L2) 50176 23848 26328
    localRam(L1) 16384 5872 10512
    Starting Sensor (issuing MMWave_start)
    [C674X_0] Data Path Stopped (last frame processing done)
    DSS Task Stack Usage (Note: Task Stack Usage) ==========
    initTask 4096 716 3380
    Task Name Size Used Free
    ObjDet DPM 4096 2308 1788
    HWI Stack (same as System Stack) Usage ============
    Size Used Free
    2048 748 1300
    [Cortex_R4_0] Data Path Stopped (last frame processing done)
    ============================================
    MSS Task Stack Usage (Note: Task Stack Usage) ==========
    Task Name Size Used Free
    Init 2048 1752 296
    Mmwave Control 3072 2368 704
    ObjDet DPM 8192 4928 3264
    HWI Stack (same as System Stack) Usage ============
    Size Used Free
    2048 1080 968
    Sensor has been stopped: startCount: 1 stopCount 1
    Starting Sensor (issuing MMWave_start)
    [C674X_0] Data Path Stopped (last frame processing done)
    DSS Task Stack Usage (Note: Task Stack Usage) ==========
    initTask 4096 716 3380
    Task Name Size Used Free
    ObjDet DPM 4096 2308 1788
    HWI Stack (same as System Stack) Usage ============
    Size Used Free
    2048 748 1300
    [Cortex_R4_0] Data Path Stopped (last frame processing done)
    ============================================
    MSS Task Stack Usage (Note: Task Stack Usage) ==========
    Task Name Size Used Free
    Init 2048 1752 296
    Mmwave Control 3072 2368 704
    ObjDet DPM 8192 4928 3264
    HWI Stack (same as System Stack) Usage ============
    Size Used Free
    2048 1080 968
    Sensor has been stopped: startCount: 2 stopCount 2
    Starting Sensor (issuing MMWave_start)
    [C674X_0] Data Path Stopped (last frame processing done)
    DSS Task Stack Usage (Note: Task Stack Usage) ==========
    initTask 4096 716 3380
    Task Name Size Used Free
    ObjDet DPM 4096 2308 1788
    HWI Stack (same as System Stack) Usage ============
    Size Used Free
    2048 748 1300
    [Cortex_R4_0] Data Path Stopped (last frame processing done)
    ============================================
    MSS Task Stack Usage (Note: Task Stack Usage) ==========
    Task Name Size Used Free
    Init 2048 1752 296
    Mmwave Control 3072 2368 704
    ObjDet DPM 8192 4928 3264
    HWI Stack (same as System Stack) Usage ============
    Size Used Free
    2048 1080 968
    Sensor has been stopped: startCount: 3 stopCount 3

    I tested it several times, we get TLV's out of the radar, and the datapath appears to run as expected.  This is without the mmWave_link interface integrated into the code.

    We then load it with a new configuration using, but at the end including these two commands for CW:
    mmwDemo:/>dfeDataOutputMode 2
    Done
    mmwDemo:/>contModeCfg 60.25, 0, 0, 10000, 0, 131072, 30, 0, 256
    Done
    mmwDemo:/>sensorStart

    After sensorStart we get:


    Exce{module#34}: line 215: error {id:0x10000, args:[0x20b18, 0x20b1c]}
    xdc.runtime.Error.raise: terminating execution.

    So the code at this point seems stable for normal operation, but the mss appears to crash when sending in the CW configuration.  I'm now going to try and add in the mmwave_link code, and I'll see if we can directly start the sensor from it.   I'll let you know what we get back at that point.

    -TomG.

  • Hi Thomas,

    I want to help out here while Angie is busy for a bit. But I want to back up and make sure we are still trying to get to what you need. You just need a CW output at a certain frequency to use for the FCC testing right? So you will set this up in an anechoic chamber and have a separate antenna looking at the output? I am not sure if what you are trying to do is beyond that with the above code mods.

    This should still be achievable with the StudioCLI tool mentioned earlier. The ICboost and DCA are only if you need to collect the data. If you have a UART connection to either the EVM or your custom board. You won't be able to do much but this is the usually the only use case needed. There won't be any data coming back in with CW mode though, so you will just need to verify with an external antenna.

    I think you tried this already, could you please list again what you tried? You should be able to connect to the studioCLI binary through a serial terminal program like putty or teraterm via USB/UART and load in the CFG file. There is one example provided for 77GHz that you should be able to just modify the start frequency with the 6843 binary provided in the folder.

    Hopefully that helps you get what you need, but please let me know again if we missed some of the requirements.

    Regards,

    Jackson

  • Hello Jackson,

    Thanks for reaching out.  I'm performing development on a Windows system with a IWR6843ISK attached to a BOOST board.  I'm running the debugger out of Code Composer Studio.  I looked briefly at StudioCLI, but it looks like it runs in the cloud and I'm already setup to run locally on my Windows system, and we won't be able to run from my development system during the FCC test.  The target system runs on an Ubuntu system, and it won't have the development environment on it either, nor does it have the ability to flash binaries to the TI board - but we could look into that.  We are not looking to collect data (using the DCA/BOOST), since we'll be using a spectrum analyzer to collect the data for us.  If you can point me at the studioCLI binary and CFG file (which I will modify for 60GHz) I will look at giving that a try.

    Where I'm at currently is that I have taken the traffic monitoring lab from mmwave_industrial_toolbox_4_12_0, and imported it into CCS.  It was configured initially for SDK 03_05_00_04, but I updated it to 03_06_00_00-LTS.  I've been able to compile it and get it to run the 68xx_traffic_monitoring_70m_MIMO_3D.cfg configuration.  I had initially started with the Long_Range_People_Detection lab, but had issues getting it to run correctly.  In any case, properly configured I get TLV's out the dataport with the traffic monitoring code.  I've then modified that code to include the cli_mmwave.c files so I can add in the functionality for "dfeDataOutputMode 2" and "contModeCfg 60.25, 0, 0, 10000, 0, 131072, 30, 0, 256" - though it's not clear if the code for these commands actually works.  It looks like it does not, or that it causes the system to crash when run.

    So, Angie suggested using the mmwavelink/test files to get direct access to calls in the SDK to potentially force the system into CW.  I've incorporated some of those calls into the contModeCfg interface in the cli_mmwave.c module:

    static int32_t CLI_MMWaveContModeCfg (int32_t argc, char* argv[])
    {
    MMWave_ContModeCfg *contCfg = &gCLIMMWaveControlCfg.u.continuousModeCfg;

    /* Sanity Check: Minimum argument check */
    if (argc != 10)
    {
    CLI_write ("Error: Invalid usage of the CLI command\n");
    return -1;
    }

    /* Sanity Check: Continuous configuration is valid only for the Continuous Mode: */
    if (gCLIMMWaveControlCfg.dfeDataOutputMode != MMWave_DFEDataOutputMode_CONTINUOUS)
    {
    CLI_write ("Error: Configuration is valid only if the DFE Output Mode is Continuous\n");
    return -1;
    }

    /* Populate the configuration: */
    contCfg->cfg.startFreqConst = (uint32_t) (atof(argv[1]) * (1U << 26) /
    gCLI_mmwave_freq_scale_factor);
    contCfg->cfg.txOutPowerBackoffCode = (uint32_t) atoi (argv[2]);
    contCfg->cfg.txPhaseShifter = (uint32_t) atoi (argv[3]);
    contCfg->cfg.digOutSampleRate = (uint16_t) atoi (argv[4]);
    contCfg->cfg.hpfCornerFreq1 = (uint8_t) atoi (argv[5]);
    contCfg->cfg.hpfCornerFreq2 = (uint8_t) atoi (argv[6]);
    contCfg->cfg.rxGain = (uint16_t) atoi (argv[7]);
    /*argv[8] is reserved*/
    contCfg->dataTransSize = (uint16_t) atoi (argv[9]);

    //go ahead and start the sensor at this point -TLG
    //System_printf ("Debug: mmwave link test init\n"); //TLG
    CLI_write ("gCLI_mmwave_freq_scal_factor is: %d\n", gCLI_mmwave_freq_scale_factor);
    CLI_write ("startFreqConst is: %d\n", contCfg->cfg.startFreqConst);
    CLI_write ("Debug: MmwaveLink_initLink\n");
    MmwaveLink_initLink(RL_AR_DEVICETYPE_68XX, RL_PLATFORM_MSS);

    //It's not clear if the dfeDataOutputMode 2 and
    //contModeCfg 60.25, 0, 0, 10000, 0, 131072, 30, 0, 256 settings are actually
    //setting up CW in the BSS correctly - so let's try and do it through the link_text.c interface

    //Let's try to enable ContMode
    CLI_write ("Debug: MmwaveLink_enableContMode\n");
    MmwaveLink_enableContMode(1U);

    //Let's and then configure the mode, similar to our CLI command config...
    CLI_write ("Debug: MmwaveLink_setContModeConfig\n");
    MmwaveLink_setContModeConfig();

    CLI_write ("Debug: CW configured, starting sensor...\n");
    MmwaveLink_sensorStart();
    CLI_write ("Debug: sensor start attempted\n");
    return 0;
    }

    The code compiles and runs to an extent.   The system initializes on the debugging Boost board:
    [Cortex_R4_0] **********************************************
    Debug: Launching the MMW Demo on MSS
    **********************************************
    Debug: Launched the Initialization Task
    Debug: UART_init completed
    Debug: GPIO_init completed
    Debug: Mailbox_init completed
    Debug: LVDS stream init completed
    Debug: cqSat Config completed
    Debug: UART Logging Setup completed
    Debug: mmWave Control Initialization was successful
    Debug: mmWave Control Synchronization was successful
    Debug: mmWave Control Execution Task setup was successful
    Debug: DPM Module Initialization of L3 CoreRam EDMA and HWA
    Debug: DPM Module Call-backs initialized
    Debug: DPM Module Initialization configuration completed
    Debug: DPM Module Initialization complete
    Debug: DPM Synchronization complete
    Debug: DPM task launched
    Debug: Cycleprofiler Initialized
    [C674X_0] Debug: DPM Module Sync is done
    [Cortex_R4_0] Debug: CLI is operational

    You can see that the MSS and DSS are running and synced. I then start configuring the system and checking on its status using the CLI:
    ******************************************
    xWR68xx MMW Demo 03.06.00.00
    ******************************************
    mmwDemo:/>version
    Platform : xWR68xx
    Integrity Comm CDOT Vers: 00.00.01c 01-24-2023 traffic monitoring base
    mmWave SDK Version : 03.06.00.00
    Device Info : IWR68XX QM non-secure ES 02.00
    RF F/W Version : 06.03.02.06.20.08.11
    RF F/W Patch : 00.00.00.00.00.00.00
    mmWaveLink Version : 01.02.06.06
    Lot number : 3837693
    Wafer number : 7
    Die coordinates in wafer: X = 18, Y = 17
    Done
    mmwDemo:/>queryDemoStatus
    Sensor State: 0
    Data port baud rate: 921600
    Done
    mmwDemo:/>sensorStop
    Ignored: Sensor is already stopped
    Done
    mmwDemo:/>flushCfg
    Done
    mmwDemo:/>dfeDataOutputMode 1
    Done
    mmwDemo:/>channelCfg 15 7 0
    Done
    mmwDemo:/>adcCfg 2 1
    Done
    mmwDemo:/>adcbufCfg -1 0 1 1 1
    Done
    mmwDemo:/>profileCfg 0 60 8 7 28 0 0 20 1 256 12500 0 0 48
    Done
    mmwDemo:/>chirpCfg 0 0 0 0 0 0 0 1
    Done
    mmwDemo:/>chirpCfg 1 1 0 0 0 0 0 4
    Done
    mmwDemo:/>chirpCfg 2 2 0 0 0 0 0 2
    Done
    mmwDemo:/>frameCfg 0 2 40 0 50 1 0
    Done
    mmwDemo:/>lowPower 0 0
    Done
    mmwDemo:/>guiMonitor -1 1 0 0 0 0 0
    Done
    mmwDemo:/>cfarCfg -1 0 2 8 4 3 0 15 0
    Done
    mmwDemo:/>cfarCfg -1 1 0 4 2 3 1 15 0
    Done
    mmwDemo:/>multiObjBeamForming -1 1 0.5
    Done
    mmwDemo:/>clutterRemoval -1 1
    Done
    mmwDemo:/>calibDcRangeSig -1 0 -5 8 256
    Done
    mmwDemo:/>extendedMaxVelocity -1 1
    Done
    mmwDemo:/>bpmCfg -1 0 0 1
    Done
    mmwDemo:/>lvdsStreamCfg -1 0 0 0
    Done
    mmwDemo:/>compRangeBiasAndRxChanPhase 0.0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0
    Done
    mmwDemo:/>measureRangeBiasAndRxChanPhase 0 1.5 0.2
    Done
    mmwDemo:/>CQRxSatMonitor 0 3 4 63 0
    Done
    mmwDemo:/>CQSigImgMonitor 0 127 4
    Done
    mmwDemo:/>analogMonitor 0 0
    Done
    mmwDemo:/>aoaFovCfg -1 -90 90 -90 90
    Done
    mmwDemo:/>cfarFovCfg -1 0 0 80
    Done
    mmwDemo:/>cfarFovCfg -1 1 -30 30.00
    Done
    mmwDemo:/>staticBoundaryBox -40 40 20 70 -0.5 3
    Done
    mmwDemo:/>boundaryBox -50 50 10 80 -0.5 3
    Done
    mmwDemo:/>gatingParam 20 15 15 15 200
    Done
    mmwDemo:/>stateParam 15 10 10 1000 10 1000
    Done
    mmwDemo:/>allocationParam 60 50 1 3 5 50.0
    Done
    mmwDemo:/>maxAcceleration 50 50 0.1
    Done
    mmwDemo:/>trackingCfg 1 2 250 20 76 379 50
    Done
    mmwDemo:/>sensorPosition 2 0 0
    Done
    mmwDemo:/>presenceBoundaryBox -3 3 2 6 0.5 2.5
    Done
    mmwDemo:/>sensorStart
    Debug: Init Calibration Status = 0xffe
    Done

    The sensor starts, and we start getting TLV's on the data port:
    Debug: Sending rlRfSetLdoBypassConfig with 0 0 0
    ============ Heap Memory Stats ============
    Size Used Free DPCUsed
    System Heap(TCMB) 98304 31360 66944 3072
    L3 786176 491520 294656
    localRam(TCMB) 4096 512 3584
    ============ Heap Memory Stats ============
    Size Used Free DPCUsed
    System Heap(L2) 32768 16008 16760 0
    L3 786176 32768 753408
    localRam(L2) 50176 23848 26328
    localRam(L1) 16384 5872 10512
    Starting Sensor (issuing MMWave_start)

    checking on the status through an additional command in the CLI we've setup, it tells us it is running based on its state:
    mmwDemo:/>queryDemoStatus
    Sensor State: 2
    Data port baud rate: 921600
    Done

    We then stop the sensor
    mmwDemo:/>sensorStop
    Done
    mmwDemo:/>

    And the MSS/DSS report the following:
    [C674X_0] Data Path Stopped (last frame processing done)
    DSS Task Stack Usage (Note: Task Stack Usage) ==========
    initTask 4096 764 3332
    Task Name Size Used Free
    ObjDet DPM 4096 2308 1788
    HWI Stack (same as System Stack) Usage ============
    Size Used Free
    2048 1080 968
    [Cortex_R4_0] Data Path Stopped (last frame processing done)
    ============================================
    MSS Task Stack Usage (Note: Task Stack Usage) ==========
    Task Name Size Used Free
    Init 2048 1752 296
    Mmwave Control 3072 2368 704
    ObjDet DPM 8192 4760 3432
    HWI Stack (same as System Stack) Usage ============
    Size Used Free
    2048 808 1240
    Sensor has been stopped: startCount: 1 stopCount 1

    We then make an attempt to reconfigure for CW mode:
    mmwDemo:/>dfeDataOutputMode 2
    Done
    mmwDemo:/>contModeCfg 60.25, 0, 0, 10000, 0, 131072, 30, 0, 256
    gCLI_mmwave_freq_scal_factor is: 256
    startFreqConst is: 1497521872
    Debug: MmwaveLink_initLink
    Debug: MmwaveLink_setContModeConfig
    Debug: CW configured, starting sensor...
    Debug: sensor start attempted
    Done
    mmwDemo:/>

    The debugger response is as follows:
    Debug: CRC Channel @080117f8 has been opened successfully
    Debug: Launched the mmwaveLink Management Task
    Debug: BSS Mailbox Handle @08001d78
    Debug: Disabling the device
    Debug: BSS Mailbox Handle @08001d78
    Debug: Power on request successfully passed to the BSS
    Debug: Finished rlSetContModeConfig
    {module#9}: "../objdetrangehwa.c", line 642: error {id:0x10000, args:[0x221bc, 0x221bc]}
    xdc.runtime.Error.raise: terminating execution
    [C674X_0] xdc.runtime.Main: "../dss/objectdetection.c", line 1985: assertion failure

    At this point I'm adding in the following code into the CLI_MMWaveConModeCfg command:

    //Let's try to enable ContMode
    CLI_write ("Debug: MmwaveLink_enableContMode\n");
    MmwaveLink_enableContMode(1U);

    That's where I am currently.  Without the MmwaveLink_setContModeConfig the system will actually run without erroring out after the MmwaveLink_initLink() command and then the MmwaveLink_sensorStart() command, and I get a data-path running TLVs back - but I'm not sure if it's really running CW at that point.  I suspect it's actually running the previous configuration settings.  The fact that I'm getting TLVs back in CW seems suspicious.  When using the MmwaveLink interface, the DSS appears to crash trying to run a data-path when forcing it into CW mode.

    Though it's not currently working, it seems close.  If I can configure it and in CW mode without the DSS or the MSS crashing, and then softReset the system for normal operation - that would be ideal.

    Best Regards,

    -TomG.

  • Hi Tom,

    Thanks for the summary. If you are trying to use soft reset to switch between regular demo and CW mode then it seems you are on the right path. Except that if you are just doing it for testing purposes it should be quick enough to re-flash the different binaries? Since you mention the target system will have this ability I recommend getting this to work as it should be more simple.

    The studio CLI tool does have many features and can get a little complicated. But since you don't need any data and just need to enable CW output, it should actually be very simple. You shouldn't need any real program, certainly no cloud connection. The BIN file from the studioCLI tool will run on the IWR device and the CFG can be sent from just about any host over USB/UART. They are located below (paths may be slightly different on your machine)

    C:\ti\radar_toolbox_1_00_00_26\tools\studio_cli\prebuilt_binaries

    C:\ti\radar_toolbox_1_00_00_26\tools\studio_cli\src\profiles\profile_continuous_mode_xwr18xx.cfg

    Hopefully that works to get you what you need without all the extra rebuilding. 

    Regards,

    Jackson

  • Jackson,

    Thanks - I'll take a look and see if we can use the binary and config files to run CW.  To swap binaries on our Ubuntu system, we'd need to be able to flash the device from Ubuntu.  Is there a UniFlash version that we can run from Ubuntu for this purpose?  The systems integrations expert on the team is asking about code availability to possibly compile and install on our target production device.

    Regards,

    -TomG.

  • Hello Thomas,

    Yes, uniflash does have a linux download. You should also be able to use that download to make a standalone executable program that will flash the device from command line. This might be the most helpful.

    Regards,

    Jackson

  • Do you know if the downloadable uniFlash Linux Installer supports Ubuntu aarch64 linux?  I believe we're running 20.04.

    Regards,

    -TomG.

  • That info should be in the release notes on the downloads page. If it is not the please make a separate ticket asking just about uniflash and it will be routed to the appropriate team.

    https://www.ti.com/tool/UNIFLASH#downloads 

    Regards,

    Jackson

  • We don't see anything in the release notes to says it does or does not support aarch64, so we've setup a seperate ticket: (+) IWR6843ISK: Is there a version of UniFlash that supports Ubuntu 20.04 aarch64? - Sensors forum - Sensors - TI E2E support forums

  • Ok hope that helps. I do think the SBL Josh is recommending there should be what you need if Uniflash won't work with your setup.

    --Jackson

  • I don't think we can use it to load the studio CLI  tool binary file since we can only download the MSS using the SBL interface.  Is that correct?  If it is, I don't think it's going to work for us - since that would be needed for the FCC test setup we were discussing previously.  We won't be able to bring a development system out there to flash the device to go between chirped testing (which we've done using in house code developed for the TI board), and CW testing.  So it still looks like we will need a solution that allows us to run CW from our in-house developed solution, based on your labs and integrating the mmwavelink interface.

    Let me know though if I've misinterpreted anything in my quick scan of the SBL interface.

    Regards,

    -TomG.

  • Hi Thomas,

    I will let you keep going with the other, more targeted thread on this topic to avoid duplicates. The short answer is that the SBL will load in any image needed, and can load a full image with MSS+DSS+BSS FW/SW, just like uniflash. There is a file size limit to the existing implementation but this could be modified if needed.

    Regards,

    Jackson