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.

AWR1642BOOST: How is mailbox being used by mmwave control link library?

Part Number: AWR1642BOOST

Hi,

I've been developing an application on "mmwave_sdk_01_02_00_05", but sometimes I'm facing issues with the mailbox.

I'm getting assertion from the file "mmwave_xwr16xx.c", if the mailbox read fails.

Can you please explain how is this mailbox being used in mmwave control library and how it conflicts with the mailbox in mmw demo folder?

Thanks,
Chidvilas

  • Hi,

    Can you provide more details - what is happening at the time of the assert?  Does the assert happen during config, when the chirps are started, or later?  Is this code based on the mmw demo, or is it entirely new?  If based on the demo, what have you changed?

      -dave

  • Hi Dave,

    I'm using mmw demo in the SDK, but I've made modifications to the code.

    Modifications:
      After angle estimation, copying the detections information into HSRAM and then sending a message to MSS via Mailbox to transmit this information over UART. Before sending the message to MSS, I'm decrementing the "gMmwDssMCB.dataPathContext.interFrameProcToken--;" and removed "interFrameProcToken--" in the switch case "MMWDEMO_MSS2DSS_DETOBJ_SHIPPED:", so that this decrement happens only once per frame.


    The assert is random, but it doesn't come when configuring the sensor. I think the reason for this assert is the mailbox channel id is not getting matched (like gMailboxMCB.mssDssReadChIDInUse != driver->cfg.chId). It seems that both the mailbox channels are clashing. 

    Could you please explain how important is this mailbox in mmwave link library and suggest me how to avoid this.

    Thanks,
    Chidvilas

  • Hi Chidvilas,

    >After angle estimation, copying the detections information into HSRAM and then sending a message to MSS via Mailbox to transmit this information over UART

    There should be no need to add another transfer, and related code. See MmwDemo_DSS_SendProcessOutputToMSS; if you need a different object to be sent, the best way is to define another TLV and send it with the existing frame rate transfer.

      -dave

  • Hi Dave,

    We are using a different format to transfer over UART.

    In mmw demo, frame periodicity should be configured such that it includes chirp acquisition time, the processing time and UART transmission time. I want to remove the dependency of UART transmission time in the frame time configured.

    Can you please explain, why this mailbox clash happens? What is the role of the mailbox in mmwave link library?

    Thanks,
    Chidvilas

  • >. I want to remove the dependency of UART transmission time in the frame time configured.

    This is not a good idea, because even if the frame time did include the UART transmission time, the UART transfer is not done by the DSS, but rather by the MSS so that it is not bound by the upcoming frame boundary.

    Please read the TRM chapter on the Mailbox peripheral.  You'll find that there are 6 independent mailboxes, one for each direction for each pair of cores.  The BSS mailboxes are used to communicate with the DSS and MSS, and are independent of the DSS <-> MSS mailboxes.  There cannot be a "clash".  Mostly likely your configuration is not setting up the required RTOS objects correctly.  I stand by my earlier statement - your best bet is to add a new data type (a TLV) to the existing frame rate transfer.

      -dave

  • Hi Dave,

    Understood your concern on UART changes, since we're not using TLV format our UART payload is very small, takes few milliseconds time to transmit and it is finishing within the chirps acquisition time itself.

    In the SDK mmw demo, in both, "mss_mmw.cfg" and "dss_mmw.cfg" files mailbox component is not used, so I think the mailbox in "ti/drivers/mailbox" is getting used by the demo(not the TI-RTOS mailbox).

    I think mailbox_write is being used by both mmw demo(modified) and mmwave link library at the same time and then for mmwave link library Mailbox_write is returning "MAILBOX_ECHINUSE".

    My inference is based on the value(post crash): gMailboxMCB.mssDssWriteChIDInUse = 0 (i.e. mailbox channel 0 is being in use(by mmw demo))

    so the following code in "ti/drivers/mailbox/src/mailbox.c:Mailbox_write" would return "MAILBOX_ECHINUSE":

    622: /* Critical Section Protection*/
            key = HwiP_disable();
            if(gMailboxMCB.mssDssWriteChIDInUse == MAILBOX_UNUSED_CHANNEL_ID)
            {
                /* Mark that the TX mailbox is now in use*/
                gMailboxMCB.mssDssWriteChIDInUse = driver->cfg.chId;
                /* Release the critical section: */
                HwiP_restore(key);
            }
            else
            {
                /* Error: TX mailbox is being used by another mailbox instance*/
                DebugP_log2 ("MAILBOX: Mailbox_write Error! handle=(%p). Write attempt with TX box in use by channel ID %d\n",driver, gMailboxMCB.mssDssWriteChIDInUse);
                retVal = MAILBOX_ECHINUSE;
                /* Release the critical section: */
                HwiP_restore(key);
                goto exit;
     639: }

    Crash report when this happens,

    {module#8}: "platform/mmwave_xwr16xx.c", line 1342: error {id:0x10000, args:[0x81bbec, 0x81bbec]}
    xdc.runtime.Error.raise: terminating execution
    [Cortex_R4_0] xdc.runtime.Main: "mss/mss_main.c", line 3504: assertion failure
    xdc.runtime.Error.raise: terminating execution

    Could you help me in resolving this issue?

    Thanks,
    Chidvilas

  • Please provide an update on this.

    Thanks, 
    Chidvilas

  • I think you have two choices:

    1) Try to continue using the Mailbox.  You run the risk of interfering with chirp processes if you do this.  You're going to need to (at a minimum) poll on gMailboxMCB.mssDssWriteChIDInUse until it is free. You could also possibly establish a semaphore to protect it's use.

    2) Use another mechanism to send the UART data from DSS to MSS. Global (shared) memory is probably the easiest - just place the data in a known memory location, use a word of memory as a flag word to the MSS, and let MSS consume it.

      -dave