• State
  • Locked Locked
  • Replies 10 replies
  • Subscribers 30 subscribers
  • Views 657 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

IWR6843: UART_write blocking with & w/o DMA

Viktor
Prodigy 10 points
Part Number: IWR6843

I am developing an application on top of the Industrial Toolbox 4.12.1 Overhead 3D People Counting lab and have a few questions.

I have UART 1 & 3 configured with both RX & TX lines as follows:

   /* Setup the PINMUX to bring out the UART-1 */
    Pinmux_Set_FuncSel(SOC_XWR68XX_PINN5_PADBE, SOC_XWR68XX_PINN5_PADBE_MSS_UARTA_TX);
    Pinmux_Set_OverrideCtrl(SOC_XWR68XX_PINN5_PADBE, PINMUX_OUTEN_RETAIN_HW_CTRL, PINMUX_INPEN_RETAIN_HW_CTRL);
    Pinmux_Set_FuncSel(SOC_XWR68XX_PINN4_PADBD, SOC_XWR68XX_PINN4_PADBD_MSS_UARTA_RX);
    Pinmux_Set_OverrideCtrl(SOC_XWR68XX_PINN4_PADBD, PINMUX_OUTEN_RETAIN_HW_CTRL, PINMUX_INPEN_RETAIN_HW_CTRL);

    /* Setup the PINMUX to bring out the MSS UART-3 */
    Pinmux_Set_OverrideCtrl(SOC_XWR68XX_PINF14_PADAJ, PINMUX_OUTEN_RETAIN_HW_CTRL, PINMUX_INPEN_RETAIN_HW_CTRL);
    Pinmux_Set_FuncSel(SOC_XWR68XX_PINF14_PADAJ, SOC_XWR68XX_PINF14_PADAJ_MSS_UARTB_TX);
    Pinmux_Set_OverrideCtrl(SOC_XWR68XX_PINP4_PADBB, PINMUX_OUTEN_RETAIN_HW_CTRL, PINMUX_INPEN_RETAIN_HW_CTRL);
    Pinmux_Set_FuncSel(SOC_XWR68XX_PINP4_PADBB, SOC_XWR68XX_PINP4_PADBB_MSS_UARTB_RX);

I am testing the following on UART-3 @ 115k baudrate.

When I have 2 back-to-back UART_write calls (without DMA), it seems that the buffer is overwritten by the second call, which causes malformed data being received on the PC. What causes this issue? The driver documentation mentions that UART_write is blocking. Therefore, I would expect the first call to block until all data has been written, and then the second call should be executed. 
However, if I change all UART_writes to UART_writePolling, it seems to fix the issue.

If I add a sleep(20) between the two UART_writes, that fixes it too (unless I am transmitting a really large packet, in which case I see some overwrites depending on the packet size).

Lastly, if I use DMA with UART_write, that mostly fixes the issue, but causes a few corrupted packets.

Further, I am facing some application specific issues when I enable DMA on UART-3 and use UART_write. I don't expect a direct resolution on this since I'm unable to share the code now. However, I want to understand if there are any foreseeable issues that I could encounter when I enable DMA on UART-3 for both RX & TX, and if I should be aware of any caveats? 

  • 0
    TI__Mastermind 37785 points

    Hi Viktor,

    I'm sharing this internally to see if there are any caveats you should be aware of. I will respond back to you by tomorrow with any information I get.

    Best,

    Nate

  • 0 in reply to Nathan Block
    TI__Mastermind 37785 points

    Hi Viktor,

    Looking at the documentation, the behavior you're seeing seems to align with what we'd expect. The description for UartSci_writePolling() in uartsci.c says:

    " * The function is the registered callback function which is invoked when
    * the data is to be written to the UART Driver but this will poll the UART
    * driver in a while loop and will only return once all the data has been
    * sent out."

    Best,

    Nate

  • 0 in reply to Nathan Block
    Prodigy 10 points

    Appreciate your prompt response, Nathan. I understand why writePolling works. 

    However, my initial question was why write doesn't work as expected?

    The description of UART_write in UART.h says:

    "* In UART_MODE_BLOCKING, UART_write() will block task execution until all
    * the data in buffer has been written."
    However, as described in my original post, when I have 2 adjacent calls to UART_write, the second write seems to overwrite the data of the first write. Why does this happen, despite the UART_write function blocking? (I use default parameters to configure UART port, so it should be in BLOCKING mode by default, as per docs).
    Note that I am testing this with DMA disabled on UART-3. It would be great if you can refer to my original post regarding the same.
  • 0 in reply to Viktor
    TI__Mastermind 37785 points

    Hi Viktor,

    Thank you for clarifying. Can you confirm that you're initializing the parameters UART-3 correctly with a call to UART_Params_init()? Can you share that piece of code with me?

    Best,

    Nate

  • 0 in reply to Nathan Block
    TI__Mastermind 37785 points

    You could also monitor the status of the semaphore on line 1227 of uartsci.c to see that it's blocking? Perhaps this semaphore is timing out?

    Best,

    Nate

  • 0 in reply to Nathan Block
    Prodigy 10 points

    I believe the initialization is correct:

    /* Setup the default UART Parameters */
    UART_Params_init(&uartParams);
    uartParams.writeDataMode = UART_DATA_BINARY;
    uartParams.readDataMode = UART_DATA_BINARY;
    uartParams.clockFrequency = gMmwMssMCB.cfg.platformCfg.sysClockFrequency;
    uartParams.baudRate = 115200;
    uartParams.readEcho = UART_ECHO_OFF;
    uartParams.readReturnMode = UART_RETURN_FULL;
    }
    // uartParams.dmaHandle = gMmwMssMCB.dmaHandle;
    // uartParams.txDMAChannel = UART_DMA_TX_CHANNEL;
    // uartParams.rxDMAChannel = UART_DMA_RX_CHANNEL;

    uartParams.readTimeout = UART_WAIT_FOREVER;
    uartParams.isPinMuxDone = 1U;

    /* Open the Logging UART Instance: */
    gXMCB.uartB_Handle = UART_open(1, &uartParams);
    if (gXMCB.uartB_Handle == NULL)
    {
    System_printf("Error: Unable to open the Logging UART Instance\n");
    Pcount3DDemo_debugAssert (0);
    return;
    }
  • 0 in reply to Nathan Block
    Prodigy 10 points

    I tried putting breakpoints inside the TIMEOUT branch of semphore, but that wasn't triggered. I didn't observe any timeout message in log2 either. (semaphore log2 is enabled)

  • 0 in reply to Viktor
    TI__Mastermind 37785 points

    Hi Viktor,

    Can you confirm that you can place breakpoints in the uart files? If they're pre-compiled you may not be able to step through them. You would have to drag the folder into your CCS project and compile it each time. Please confirm that you can place a breakpoint in the UART functions at all.

    Best,

    Nate

  • 0 in reply to Nathan Block
    Prodigy 10 points

    Yes, I am able to set and use breakpoints in uartsci.c. As seen in this screenshot, the breakpoint was hit, indicated by the small red mark before line number:

    Also note the breakpoint on line 1235, which is never hit.

  • 0 in reply to Viktor
    TI__Mastermind 37785 points

    Hi Viktor,

    Thank you for clarifying. I am somewhat confused here because if you're using the logging UART, then we have many instances where we have nearly back-to-back calls to the logging UART in the MmwDemo_uartTxTask function. Do you see overwriting and problems with the typical output when you turn the DMA off? Or only on the extra data you're outputting?

    Can you monitor the return value of the UART_write function as it gets called? It should return the number of bytes written. 

    Finally, you might consider looking at the out_of_box_6843_isk_mss project, which has a non-DMA UART example. The only differences I see between its uartParams and yours are the readReturnMode and baudrate. You might consider increasing your baud rate for the logging UART from 115200 to 921600, which is what the typical logging UART baud rate is. Perhaps that's the source of your problem?