IWR1443: Calling Semaphore_post() causes assert

Alan Gard

Part Number: IWR1443

I am working with the high_accuracy_14xx_mss lab.

Now that a basic EDMA transfer is working, I am trying to add the MmwDemo_EDMA_transferCompletionCallbackFxn() to signal the completion of the transfer. Following the existing EDMA_1Ddone_semHandle example existing in the MmwDemo_edmaInit() function, I created a EDMA_L1BackupDone_semHandle semaphore:

    Semaphore_Params_init(&semParams);
    semParams.mode = Semaphore_Mode_BINARY;
    obj->EDMA_1Ddone_semHandle = Semaphore_create(0, &semParams, NULL);

    Semaphore_Params_init(&semParams);
    semParams.mode = Semaphore_Mode_BINARY;
    obj->EDMA_L1BackupDone_semHandle = Semaphore_create(0, &semParams, NULL);

Then in the MmwDemo_EDMA_transferCompletionCallbackFxn(), I again copied what was existing in the function:

    switch (transferCompletionCode)
    {
        case MMWDEMO_EDMA_TRANSFER_COMPLETION_CODE_1D_DONE:
            Semaphore_post(obj->EDMA_1Ddone_semHandle);
        break;

case EDMA_TPCC0_REQ_FREE_2:
Semaphore_post(obj->EDMA_L1BackupDone_semHandle);
break;

When I run the code, it crashes when the Semaphore_post is called.

I find the same thing happens if I substitute the EDMA_1Ddone_semHandle for the semaphore to be posted. I also tried adding a Semaphore_reset() just before the call to post to ensure the semaphore count is 0, but the crash still occurs.

I would expect that the existing code provided in the lab is functional, but the MmwDemo_EDMA_transferCompletionCallbackFxn() is not actually used for the base build. Therefore, I cannot verify that the initial implementation of the semaphores in the lab actually works and does not create an assert.

A call to Semaphore_Module_startupDone() before the creation of the semaphore return TRUE, so the semaphore module has started. From the debug error messages, it appears that there may be a privilege or exclusion issue. The 6.53.02.00 BIOS User Guide does not indicate that there are conditions necessary for the semaphores to work. Is there something else that needs to be called, enabled, or disabled for the semaphores to work?

over 5 years ago

0 Nitin Sakhuja over 5 years ago

TI__Mastermind 30405 points

Hi Alan,

Could you do some debugging in CCS to check the following:

1. Put a breakpoint in in MmwDemo_EDMA_transferCompletionCallbackFxn and step to the case statement.

2. Check the semaphore object in the expressions window (Window->Show View->Expressions) to see is it's a valid address. (In fact, you should also check the object after creating the semaphore and compare the address at the time of Semaphore_post call.

-Nitin

0 Alan Gard over 5 years ago in reply to Nitin Sakhuja

Intellectual 390 points

Hi Nitin,

I was out the last several days. I tried your suggestion today, and you were spot on. When I looked at the MmwDemo_EDMA_transferCompletionCallbackFxn() function, I found that the function uses the 'arg' argument as the pointer to the data path object in the firmware:

MmwDemo_DataPathObj *obj = MmwDemo_DataPathObj *)arg;

This is the way it is done in several labs in the toolbox. Using a breakpoint in the function, I found that 'arg' was not set to the address of the datapath object.

The 14xx_high_accuracy lab sets a callback function and argument in the EDMAutil_configHwaTranspose() function, which I used as a model:

    config.transferCompletionCallbackFxn = transferCompletionCallbackFxn;

    if (transferCompletionCallbackFxn != NULL) {
        config.transferCompletionCallbackFxnArg = (uintptr_t) transferCompletionCallbackFxnArg;
    }

    if ((errorCode = EDMA_configChannel(handle, &config, true)) != EDMA_NO_ERROR)
    {
        System_printf("Error: EDMA_configChannel() failed with error code = %d\n", errorCode);
        goto exit;
    }

So the callback function is registered through the EDMA_configChannel() function. Note that the arguments for that function contain the EDMA handle and the config structure, but no apparent reference to the datapath object required by the callback function.

I then changed the MmwDemo_EDMA_transferCompletionCallbackFxn() function to explicitly point to the datapath object in the firmware

MmwDemo_DataPathObj *obj = &gMmwMCB.dataPathObj;

The function completes without error, and the pending on the semaphore works as well.

So it appears that somehow, the EDMA setup is missing the code that correctly sets the 'arg' in the callback function. How does that happen so that I know what went wrong and can avoid that in the future?

Best regards,

Alan

0 Nitin Sakhuja over 5 years ago in reply to Alan Gard

TI__Mastermind 30405 points

Hi Alan,

Sorry for the late response. Good debugging. I'll need to check the 14xx_high_accuracy lab but the mmw demo in SDK 2.1.0.4 does pass both the transfer completion callback function as well as the obj argument, for transfers wherethe transfer completion callback is registered. Please look at the code below.

Thanks

-Nitin

0 Nitin Sakhuja over 5 years ago in reply to Nitin Sakhuja

TI__Mastermind 30405 points

Alan, I have updated my response above. The Transfer Completion function does take the DataPathObj as you noted and the same is passed in the code snapshot I shared above.

Regards

-Nitin

Sensors

Sensors forum

IWR1443: Calling Semaphore_post() causes assert