IWR6843AOP: TI Rtos Crashes When Calling MMWave_Open

To follow up on this, our team has determined that all of the config values are not causing issues outside of:

m_mmWaveOpenCfg->calibMonTimeUnit = 1;

Which causes the rtos to crash with the error:
{module#35}: line 222: error {id:0x10000, args:[0x18a68, 0x18a6c]}
xdc.runtime.Error.raise: terminating execution

Commenting out this line makes MMWave_open() run, but populates an error code of: -205062142 and a return code of: -1

All of the demo's we look through set calibMonTimeUnit to 1 so we are puzzled why this is causing errors for us.

Hi, 

Thank you for your post and for the detailed explanation of where the issue seems to occur. Unfortunately, the RTOS error info is rarely very helpful in identifying the issue in the application. Though, from experience I can say that the xdc.runtime.Error often comes when execution gets hung up somewhere. 

calibMonTimeUnit = 1; should be fine also. As you mentioned that is used in many demos without issue. 

In developing your application, have you started from one of our examples (i.e. the Out-of-Box demo)? If so, how extensive are your changes? It may of course be difficult for us to identify the root cause of an issue in custom code but since you already seem to have narrowed down where the issue is coming from I can try to help identify the potential problem. Please let me look at this a bit deeper and get back to you next week. 

Best regards,

Josh

The code is pretty different from the provided demos, but the setup should be very similar. We added a task delay after calling MMWave_Sync() and discarded our custom hardware mailbox configurations for the time being and that has gotten us further through MMWave_Open().

We are still stuck in MMWave_openLink, but we now are stuck in MMWave_internalLinkSync forever.

Line 1956 of mmwave_link.c:     MMWave_internalLinkSync(ptrMMWaveMCB, MMWAVE_RF_INITIALIZED | MMWAVE_RF_INIT_FAILED);

We also have come across a different forum post determining that the ldo bypass config needs to be set like so:

g_rfLdoBypassCfg.ldoBypassEnable = 3;
g_rfLdoBypassCfg.supplyMonIrDrop = 1;
g_rfLdoBypassCfg.ioSupplyIndicator = 0;

But we are not seeing success with this value or all 0's for the iwr6843aop evm.

Hello, we are still having issues within the MMWave_open() function. As described in my post above, our code is stuck within:

Line 1956 of mmwave_link.c:     MMWave_internalLinkSync(ptrMMWaveMCB, MMWAVE_RF_INITIALIZED | MMWAVE_RF_INIT_FAILED);

When calling MMWave_open() and while loop runs infinitely. Our code is not setting up the datapath yet, is that necessary for this function to complete correctly?

We've determined that the only place the flag MMWAVE_RF_INITIALIZED gets set for ptrMMWaveMCB->linkStatus within MMWave_internalLinkSync() is through the MMWave_asyncEventHandler (line 685 of mmwave_link.c). This callback should not have anything to do with our code and should get set up when we call MMWave_init() with the initial configuration we already provided. Additionally we have attached our own callback to the mmwave init config which should be getting called after the async handler does it's logic (line 769 of mmwave_link.c). We are never entering our custom callback which leads us to believe that the MMWave_asyncEventHandler is never getting called despite MMWave_init() running successfully with an error code of 0 and returning a handle.

What are we missing? From what we can tell, we need MMWave_asyncEventHandler to pre-empt us and release the linkStatus flag. Yet this never happens.

Hello, 

Sorry for the delay here and thank you for the additional information. 

Michael said:

From what we can tell, we need MMWave_asyncEventHandler to pre-empt us and release the linkStatus flag.

This is correct. So either the async event message from the BSS is never sent or it is sent but it is never received. I'm curious if the event message is missed due to priority issue. What is the priority of your task? Are any additional tasks created?

I am reaching out internally to our software dev team to confirm if there are any potential issues with what you have told me about your setup. I will update you within the next 1-2 days. Thank you for your patience.

Please also let me know if there are any other major differences when comparing your code with the initialization in the out of box demo.

Best Regards,

Josh

The project our team is working on is predominately written in c++ so it structurally differs a lot from the out of box demo. We have gone through the majority of the demo located in mmwave_sdk_03_05_00_04\packages\ti\demo\xwr64xx\mmw to base our hardware initialization off of. Our understanding is this should work as well for the iwr6843aop because the 64xx lacks a dsp and we want to develop a project that excludes the dsp for a minimum viable product.

We have 5 operating tasks: Blink, Data_Transmitter, Datapath, MMWave, and Init.

Blink operates the led to report operating status easily to the developer, it is the lowest priority (1) and runs at ~2hz.

Data_Transmitter will be responsible for outputting data over the higher speed write only uart (uart3) and is event based over a sysbios mailbox. Since we are not currently publishing to this mailbox it should be waiting forever and not interfering with the rtos:

        Mailbox_pend(
            m_mailbox,
            m_dataTransmitterBuffer,
            BIOS_WAIT_FOREVER);

Datapath will run DPM execute and do the post processing of the results buffer. This task is not implemented yet as we want to get the mmwave radar running before attempting to process the data.

MMWave is responsible for running MMWave execute and that is it. It waits on a semaphore for init to complete.

//Within the mmwave task

Semaphore_pend(
    *m_initCompleteSemaphore,
    BIOS_WAIT_FOREVER);

while (true)
{
    m_mmWaveController->execute();
    Task_sleep(500);
}

For context m_mmWaveController->execute() essentially is just:

retCode = MMWave_execute(
    *m_mmWaveHandle,
    &errCode);

There's a bit more of business protection code, but it does not effect MMWave_execute from getting called when the object is correctly set up.

Init does all initialization that is required to happen within a task. Most of our hardware is set up before we start the bios. The documentation does say we need to create our mmwave handle within a task context as well as the dpm. The init task is responsible for doing both of these things. For the mmwave it calls: 

• MMWave_init
• MMWave_flushCfg
• MMWave_sync
• MMWave_addProfile
• MMWave_addChirp (3 times)
• Task_sleep(5000)
• MMWave_open -> stuck here
• MMWave_config
• MMWave_start

The intention is to then release the semaphore for the MMWave task which would allow execute to run. We can call execute part way through init in the MMWave task, but since it just pends on a semaphore itself, we don't think we have to have execute waiting for MMWave_open to work. In fact, we tried switching our order around for this to happen, and it didn't fix our problem.

The tasks priorities are as listed:

enum TaskPriorities : uint8_t
{
    BLINK = 1,
    DATA_TRANSMITTER,
    DATAPATH,
    MMWAVE,
    INIT,
};

So Init, which calls MMWave_open, is currently our most important task. It seems unlikely then that task priorities would be the reason we do not receive this callback.

We went and got a print out of the BSS' rlFwVersionParam if that helps.

BSS: 
hwVarient: 6
hwMajor: 2
hwMinor: 0
fwMajor: 6
fwMinor: 3
fwBuild: 2
fwDebug: 6
fwYear: 20
fwMonth: 8
fwDay: 11
patchMajor: 0
patchMinor: 0
patchYear: 0
patchMonth: 0
patchDay: 0
patchBuildDebug: 0