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: MMWave_init() function not working

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

Hello team,

I have a IWR6843ISK that I'm using with a MMWAVEICBOOST to learn how to develop using the mmWave SDK. So far I have the following code for the MSS that just tries to initialize the mmWave module:

#include <stdint.h>
#include <stdlib.h>
#include <stddef.h>
#include <string.h>
#include <stdio.h>

#include <ti/control/mmwave/mmwave.h>

#include <ti/drivers/soc/soc.h>
#include <ti/drivers/esm/esm.h>
#include <ti/drivers/mailbox/mailbox.h>
#include <ti/drivers/gpio/gpio.h>
#include <ti/drivers/uart/UART.h>

static int32_t my_mmwave_callbackFn(uint16_t msgId, uint16_t sbId, uint16_t sbLen, uint8_t *payload)
{
    return 0;
}

int32_t errCode;

int main(void)
{
    SOC_Handle socHandle;
    SOC_Cfg socCfg;

    ESM_init(0U);

    // Init SOC configuration to 0
    memset((void*)&socCfg, 0, sizeof(SOC_Cfg));

    // Configure SOC
    socCfg.clockCfg = SOC_SysClock_INIT;
    socCfg.mpuCfg   = SOC_MPUCfg_CONFIG;
    socCfg.dssCfg   = SOC_DSSCfg_UNHALT;

    //Initialize module
    socHandle = SOC_init(&socCfg, &errCode);
    if(socHandle == NULL)
    {
        return -1;
    }

    if (SOC_waitBSSPowerUp(socHandle, &errCode) < 0)
    {
        return -1;
    }

    if (SOC_isSecureDevice(socHandle, &errCode))
    {
        /* Disable firewall for JTAG and LOGGER (UART) which is needed by all unit tests */
        SOC_controlSecureFirewall(socHandle,
                                  (uint32_t)(SOC_SECURE_FIREWALL_JTAG | SOC_SECURE_FIREWALL_LOGGER),
                                  SOC_SECURE_FIREWALL_DISABLE,
                                  &errCode);
    }

    UART_init();
    GPIO_init();
    Mailbox_init(MAILBOX_TYPE_MSS);

    MMWave_Handle mmwaveHandle;
    
    //Prepare Init config for mmwave module
    MMWave_InitCfg mmwaveCfg;

    memset((void*)&mmwaveCfg, 0, sizeof(mmwaveCfg));

    mmwaveCfg.domain                  = MMWave_Domain_MSS;
    mmwaveCfg.socHandle               = socHandle;
    mmwaveCfg.eventFxn                = my_mmwave_callbackFn;
    mmwaveCfg.linkCRCCfg.useCRCDriver = 1U;
    mmwaveCfg.linkCRCCfg.crcChannel   = CRC_Channel_CH1;
    mmwaveCfg.executionMode           = MMWave_ExecutionMode_ISOLATION; //Only in MSS
    mmwaveCfg.cfgMode                 = MMWave_ConfigurationMode_FULL; //Radar will be configured using mmWave API instead of having to use mmWaveLink

    //EXECUTION FALIS HERE!!
    mmwaveHandle = MMWave_init(&mmwaveCfg, &errCode);
    
    MMWave_sync(mmwaveHandle, &errCode);

    return 0;
}

However, the code fails when reaching MMWave_init(), I've actually followed the execution with the CCS debug utility to find that my program fails in:

  • MMWave_init()
    • MMWave_initLink()
      • MMWave_initMMWaveLink()
        • rlDeviceGetVersion()
          • rlDeviceGetRfVersion()
            • rlDriverExecuteGetApi()
              • rlDriverCmdInvoke()
                • rlDriverCmdSendRetry() <--- Program ultimately fails here, maybe BSS is not responding to commands sent

The error code I get from the debug trace is: (I don't really know how to read these error codes)

[Cortex_R4_0] {module#34}: line 215: error {id:0x10000, args:[0x9d38, 0x9d3c]}
xdc.runtime.Error.raise: terminating execution

I would like to know what I'm possibly doing wrong. Maybe the MMWave_init() must be invoked in a task as in the demos or my approach is totally wrong? I've tried avoiding using the RTOS as I just wanted to use the mmWave SDK as low level as possible.

Some additional info that might be useful regarding my situation:

  • I'm using CCS v12.2 to develop the code, loading and debugging it.
  • I flashed the ccsdebug.bin once to the board using Uniflash and it seems to work fine as I can debug with CCS correctly, although it is quite unstable.
  • The MMWAVEICBOOST has only SOP0 with a jumper on it.
  • I loaded a copy of the demo project in CCS, erased all code regarding CLI, RF parsers, etc to have an empty main.c and started writing my code there.
  • The only code I have in the DSS is an empty main function that does nothing.
  • My ultimate goal is to be able to load my own frame and chirp configurations to the sensor using MMWave_config, I'm aware I can do this by bypassing CLI on the demos as I've read somewhere else, but I'd like to configure the sensor with the least amount of code, besides I'd like to learn using the mmwave SDK as much as possible :)

Please tell me if you need any other information that might be useful, I will appreciate any help I might receive,

Thanks.

  • Hello,

    Very sorry about the delayed response here. 

    I can debug with CCS correctly, although it is quite unstable.

    Can you please clarify, how is it unstable?

    Can you confirm that you are following the debug procedure described in this document?

    Using breakpoints, are you able to determine exactly which line of code causes the failure? For example, if one of these variables are null an error will occur. Can you check if either of these are null (rl_driver.c)?

    Maybe the MMWave_init() must be invoked in a task as in the demos

    I do not believe it is necessary to invoke MMWave_init() in its own task, however please allow me to confirm. 

    Best Regards,

    Josh

  • Hello,

    Can you please clarify, how is it unstable?

    When pressing on the "step into" or "step over" buttons on the Debug view the program executes any other line but the one that is highlighted, you can see how the disassembled instructions are all over the place in the screenshot below (lines repeating or not following the expected order), so it is hard to follow the actual program flow. This also affects the value of variables as their value change in unexpected ways and sometimes they don't even show in the "Variables" window.

    Can you confirm that you are following the debug procedure described in this document?

    Yes, the only exception being parts 3.1 and 3.2 as I eventually created my own debug configuration that automatically resets the cores and loads the programs on them, however I just tried creating a new target configuration and followed the guide and the behavior I described before still occurs.

    Using breakpoints, are you able to determine exactly which line of code causes the failure? For example, if one of these variables are null an error will occur. Can you check if either of these are null (rl_driver.c)?

    I'm going to check this again, I stopped at the "rlDriverCmdSendRetry()" function as I suspected debugging this communication between MSS and BSS was going to be tricky.

  • Hello again,

    Using breakpoints, are you able to determine exactly which line of code causes the failure? For example, if one of these variables are null an error will occur. Can you check if either of these are null (rl_driver.c)?

    I've just checked this, apparently the error is there because the code ultimately fails on the while loop of line 2562:

    while ((deviceMap != 0U) && (RL_RET_CODE_OK == retVal))

    I'm not able to confirm if any of the variables you mention is null as the variable "rlDrvData" does not show in the Variable window and the debugging session gets worse in this section (switches randomly to other previously called functions).

    But actually line 2547:

    rlDriverData_t *rlDrvData = rlDriverGetHandle();

    Doesn't even appear in the disassembly as you can see below, so I guess "rlDrvData" is null?

  • Hello,

    I'm still looking into this. Please expect a response on this tomorrow afternoon (CST).  

    the debugging session gets worse in this section (switches randomly to other previously called functions).

    If the execution is seemingly jumping around it's likely due to compiler optimization. This can be disabled in CCS for your whole project or individually on a per file basis.

    Best Regards,

    Josh

  • Hello Josh,

    Any updates on this?

    By the way, I ultimately checked and yes, my optimization configurations were causing the problems described, switching them to off and a full speed trade-off solved most of the problems, however they still persist in some functions in the "rl_driver.c" module.

    NOTE: I tried debugging the OOB demo with no changes applied at all, I created a breakpoint inside the init_task and the MMWave_Init() function still fails, so I suspect the problem is not on my code but in anything else on my setup, maybe besides the debug_css.bin I need to flash the BSS binary? I'm out of ideas at this point.

    Regards.

  • Hi, 

    Sorry again about the delay. It seems there is no reason that you shouldn't be able to invoke MMWave_init() there. 

     

    I tried debugging the OOB demo with no changes applied at all, I created a breakpoint inside the init_task and the MMWave_Init() function still fails,

     When you say MMWave_init() still fails, is the behavior the same? Does it appear to be failing in the same location? I think you are right, the issue is likely not in your code so lets take a step back and confirm that the setup is correct. 

    First, could you please clarify whether this behavior is always noticed or only when breakpoints are placed? For example, are you able to successfully run the demo in debug mode without placing any breakpoints? 

    maybe besides the debug_css.bin I need to flash the BSS binary?

    This is not required. The ccs debug binary includes the BSS image. 

    however they still persist in some functions in the "rl_driver.c" module.

    This is because rl_driver.c is part of the mmwavelink module which is compiled as a library in the SDK. You may be able to pull those files into your project locally and rebuild them without complier optimization but it would probably be more effort than it's worth. Let's first focus on being able to successfully debug the Out of Box demo with no modifications. 

    Can you also please tell me the specific version of the SDK you are using so I may be able to reproduce your issue?

    Best Regards,

    Josh

  • Hello,

     When you say MMWave_init() still fails, is the behavior the same? Does it appear to be failing in the same location?

    Yes, it still failed in the same line I mentioned some comments before.

    First, could you please clarify whether this behavior is always noticed or only when breakpoints are placed? For example, are you able to successfully run the demo in debug mode without placing any breakpoints?

    It fails in both cases, with and without breakpoints, in my code and in the demo.

    This is because rl_driver.c is part of the mmwavelink module which is compiled as a library in the SDK. You may be able to pull those files into your project locally and rebuild them without complier optimization but it would probably be more effort than it's worth. Let's first focus on being able to successfully debug the Out of Box demo with no modifications. 

    Yes, you are absolutely correct, I had built the SDK with an -O3 flag in the makefile that I wasn't aware of, after deleting it and rebuilding the SDK with no optimization flags all debugger-related problems vanished, thanks.

    However, yesterday I was able to resolve my problem:

    • I called MMWave_Init() inside a task and it worked, I tried avoiding an RTOS-based approach but it seems I have no way of escaping it so I'll work with that from now onward. Besides, a deeper read into the documentation hints that some functions like "MMWave_execute()" need an execution context to parse messages from BSS, so I guess an RTOS approach is almost mandatory, right?
    • I figured MMWave_Init() did not work in the demo only after having loaded and debugged my code of the first comment. Performing a power cycle on the board and reloading the demo made it work again. I don't know if this makes any sense, but I observed this multiple times so I'll take it as a fact, perhaps my code somehow blocked something in the HW?

    I'm marking this as a solution, however I'm open to any additional comment/suggestion you may have, thanks for your help.

    Regards.