Because of the holidays, TI E2E™ design support forum responses will be delayed from Dec. 25 through Jan. 2. Thank you for your patience.

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.

MSPM0G3507: MSPM0G3507 - UART0 TX DMA missing random bytes at 80Mhz

Part Number: MSPM0G3507
Other Parts Discussed in Thread: MSPM0G3106,

Tool/software:

Hi 

I am using the MSPM0G3106/MSPM0G3507 for a UART DMA communication running at the following configuration. 

Baud rate - 2mbps 

CPU clock - 80Mhz 

MCLK - 80Mhz 

ULPCLK - 40Mhz ( max possible as per TRM ) 

UART0 ( Power Domain 0)  being used which refers to ULPCLK at 40Mhz ( max)  as the BUSCLK for its operation. DMA is used  for RX and TX  with  the Triggers Set to transfer to and from RX/TX FIFOs. DMA ( Power Domain 1 ). 


Problem Statement: 

We are a TX Task running at 1ms , which creates packets of max 130 bytes at a time which will be the source buffer for the DMA to push to the UART TX FIFO.  With an Internal Loopback enabled , we are observing random 1 or 2 bytes missing from the Packet transmitted. we have validated the packet structure till the buffer is given for UART DMA transaction, so the issue has to be the UART/DMA  layer itself. 

Observations :

1. The same code with the MCLK and CPU CLOCK set to 40Mhz , along with ULPCLK also at 40Mhz seems to be not giving the issue. 

2. On a launchpad ,the  same test conducted by using UART3 (PD1) instead of UART0(PD0) there by using the MCLK 80Mhz for UART3(PD1) - this setup is also working with the missing of bytes. 


Is there any recommendations for using UART0 DMA with ULPCLK -40Mhz , MCLK - 80Mhz , CPU CLOCK - 80Mhz  for attaining stability ? 



Please find the code snippet for the configurations used when the issue is observed  :

Clock Configurations ( SYS PLL) :


static const DL_SYSCTL_SYSPLLConfig gSYSPLLConfig = {
    .inputFreq              = DL_SYSCTL_SYSPLL_INPUT_FREQ_16_32_MHZ,
    .rDivClk2x              = 0,
    .rDivClk1               = 0,
    .rDivClk0               = 0,
    .enableCLK2x            = DL_SYSCTL_SYSPLL_CLK2X_DISABLE,
    .enableCLK1             = DL_SYSCTL_SYSPLL_CLK1_ENABLE,
    .enableCLK0             = DL_SYSCTL_SYSPLL_CLK0_ENABLE,
    .sysPLLMCLK             = DL_SYSCTL_SYSPLL_MCLK_CLK0,
    .sysPLLRef              = DL_SYSCTL_SYSPLL_REF_SYSOSC,
    .qDiv                   = 9,
    .pDiv                   = DL_SYSCTL_SYSPLL_PDIV_2
};


    DL_SYSCTL_setSYSOSCFreq(DL_SYSCTL_SYSOSC_FREQ_BASE);
    DL_SYSCTL_configSYSPLL((DL_SYSCTL_SYSPLLConfig *) &gSYSPLLConfig);
    DL_SYSCTL_setMCLKSource(SYSOSC, HSCLK, DL_SYSCTL_HSCLK_SOURCE_SYSPLL);
    DL_SYSCTL_setULPCLKDivider(DL_SYSCTL_ULPCLK_DIV_2);
    //Low Power Mode is configured to be SLEEP0
    DL_SYSCTL_setBORThreshold(DL_SYSCTL_BOR_THRESHOLD_LEVEL_0);
    DL_SYSCTL_setFlashWaitState(DL_SYSCTL_FLASH_WAIT_STATE_2);

UART0 & DMA configurations:

DL_UART_Main_setOversampling(UART_INST, DL_UART_OVERSAMPLING_RATE_16X);

DL_UART_Main_setBaudRateDivisor(UART_INST, UART_IBRD_40_MHZ_2000000_BAUD, UART_FBRD_40_MHZ_2000000_BAUD);

DL_UART_Main_enableDMAReceiveEvent(UART_INST, DL_UART_DMA_INTERRUPT_RX);
DL_UART_Main_enableDMATransmitEvent(UART_INST);

    /* Configure FIFOs */
    DL_UART_Main_enableFIFOs(UART_INST);
    DL_UART_Main_setRXFIFOThreshold(UART_INST, DL_UART_RX_FIFO_LEVEL_ONE_ENTRY);
    DL_UART_Main_setTXFIFOThreshold(UART_INST, DL_UART_TX_FIFO_LEVEL_ONE_ENTRY);


/* Configuration for UART 0 Peripheral  */
static const DL_UART_Main_ClockConfig gUART_ClockConfig = {
    .clockSel    = DL_UART_MAIN_CLOCK_BUSCLK,
    .divideRatio = DL_UART_MAIN_CLOCK_DIVIDE_RATIO_1
};

static const DL_UART_Main_Config gUART_Config = {
    .mode        = DL_UART_MAIN_MODE_NORMAL,
    .direction   = DL_UART_MAIN_DIRECTION_TX_RX,
    .flowControl = DL_UART_MAIN_FLOW_CONTROL_NONE,
    .parity      = DL_UART_MAIN_PARITY_NONE,
    .wordLength  = DL_UART_MAIN_WORD_LENGTH_8_BITS,
    .stopBits    = DL_UART_MAIN_STOP_BITS_ONE
};




/*configuration for DMA TX channel - Channel 1*/
static const DL_DMA_Config gDMA_CH1Config = {
    .transferMode   = DL_DMA_SINGLE_TRANSFER_MODE,
    .extendedMode   = DL_DMA_NORMAL_MODE,
    .destIncrement  = DL_DMA_ADDR_UNCHANGED,
    .srcIncrement   = DL_DMA_ADDR_INCREMENT,
    .destWidth      = DL_DMA_WIDTH_BYTE,
    .srcWidth       = DL_DMA_WIDTH_BYTE,
    .trigger        = UART_INST_DMA_TRIGGER_1,
    .triggerType    = DL_DMA_TRIGGER_TYPE_EXTERNAL,
};


/*configuration for DMA RX channel - Channel 0*/
static const DL_DMA_Config gDMA_CH0Config = {
    .transferMode   = DL_DMA_FULL_CH_REPEAT_SINGLE_TRANSFER_MODE,
    .extendedMode   = DL_DMA_NORMAL_MODE,
    .destIncrement  = DL_DMA_ADDR_INCREMENT,
    .srcIncrement   = DL_DMA_ADDR_UNCHANGED,
    .destWidth      = DL_DMA_WIDTH_BYTE,
    .srcWidth       = DL_DMA_WIDTH_BYTE,
    .trigger        = UART_INST_DMA_TRIGGER_0,
    .triggerType    = DL_DMA_TRIGGER_TYPE_EXTERNAL,
};


  • Hi Jayakrishnan Menon,

    We have identified this as an errata that is going to be coming up in the next errata update, which we are planning to have available very soon. Below are the details.

    DMA_ERR_01

    DMA Module

    Category

    Functional

    Function

    DMA or CPU may lose operation when simultaneously accessing peripheral register across clock resource

    Description

    DMA and CPU are sourced from MCLK. When MCLK is running at a higher frequency than ULPCLK, DMA or CPU may lose operation when simultaneously accessing the peripheral register sourced from ULPCLK, which include all PD0 peripherals. The accessed peripheral or register does not have to be the same. Note: ADC is a PD0 peripheral, while DMA or CPU accessing SVT_MEMRES or SVT_FIFODATA of ADC has no restriction. Example: Assume that DMA access UART0 register, for example DMA write data to TXDATA, if CPU also access PD0 peripheral during DMA operation, for example CPU read data from TIMG0 CTR, then DMA or CPU may lose the data.

    Workaround

    CPU and DMA should not be accessing PD0 peripherals at the same time when MCLK is running at a higher frequency than ULPCLK.
    Regards,
    Luke
  • Hi Luke, 

    Thanks for the response.  Is this going to be fixed in the future chip revisions ?  


  • Hi Jayakrishnan,

    Currently, there are no plans for revision in the near future on this device (MSPM0G350x). For future devices it could potentially be fixed.

    Regards,
    Luke

  • Hi Luke, 

    Is the same Errata applicable for the MSPM0G3106 ? 

  • Hi Jayakrishnan,

    The same errata is applicable.

    Regards,
    Luke

  • Hi Luke, 

    If I change UART0 ( PD0) to UART3 (PD1) , BUSCLK of UART3 refers to MCLK instead  of ULPCLK. 

    So  having MCLK , CPUCLK at 80Mhz  and using UART3 (PD1), then I am not seeing the missing bytes from DMA to UART3 TX.  

    Other PD0 peripherals that are used are  TIMG0 ( for periodic Capture of performance) , WWDT0, FLASHCTL .  

    With reference to the ERRATA mentioned , Is it safe to go ahead with the change of UART0 to UART3 in the hardware ( Considering the other PD0 peripherals listed ) .  Is there anything more to be considered here ? 

    Thanks & Regards 
    Jayakrishnan 

  • Hi Jayakrishnan,

    You can have other peripherals in other power domains active, the issue is when the DMA and CPU are accessing the same peripheral in PD0 when MCLK > ULPCLK.

    Switching to UART3 in PD1 power domain is an acceptable workaround.

    Regards,
    Luke

  • Hi Luke, 

    Infact, we have also tried keeping UART0 and  changing TIMG0(PD0) to TIMG6(PD1).  Here the scenario remains like UART0 using ULPCLK , MCLK > ULPCLK. With this setup also we were not seeing the issue of packet missing for DMA to UART0 TX.  
    As per Errata description -  Example: Assume that DMA access UART0 register, for example DMA write data to TXDATA, if CPU also access PD0 peripheral during DMA operation, for example CPU read data from TIMG0 CTR, then DMA or CPU may lose the data.


    Which of the 2 options below can be better acceptable workaround considering future scope on the same system with usage of PD0 peripherals. 
    1. Changing UART0 to UART3 

    2. Changing TIMG0 to TIMG6 
     

    Thanks & Regards
    Jayakrishnan

  • Hi Jayakrishnan,

    Sorry about my previous post, the errata does go with different peripherals on the same power domain.

    If you transition the timer to PD1 then you can access it with the CPU, if the DMA is handling the PD0 UART. You can also go and set the DMA to handle all PD0 peripherals (or PD1) that way you guarantee the CPU and DMA don't access PD0 peripherals at the same time.

    I would personally have the DMA handle the communication data, as it is common across applications to do some processing on the data you receive and this allows the CPU to continue processing data while you have an active communication.

    Regards,
    Luke

  • Hi Luke, 

    1. "If you transition the timer to PD1 then you can access it with the CPU, if the DMA is handling the PD0 UART. You can also go and set the DMA to handle all PD0 peripherals (or PD1) that way you guarantee the CPU and DMA don't access PD0 peripherals at the same time."

    So In the case , when UART0 is used with DMA, and with TIMG0 , the CPU read to TIMG0 is what causing the errata  , So Is it like if we prevent the CPU read of TIMG0 , replacing with PD1 TIMG6 , then we are good to use DMA with any PD0 peripherals including UART0 ?  "It is only the CPU read of PD0 peripherals that causes the conflict or Is there any effect with CPU write ?"  

    This can be one of working without ERRATA, but provided there can be potential issues if there has to be PD0 CPU access in future ?


    2. "I would personally have the DMA handle the communication data, as it is common across applications to do some processing on the data you receive and this allows the CPU to continue processing data while you have an active communication."

    Considering we use UART3 with DMA for the main communication channel, then we are good to access any other PD0 peripherals without the dependency on ERRATA right ? 


    Thanks & Regards
    Jayakrishnan 

  • Hi Luke, 

    Can you please confirm, if it is only the CPU read access  to PD0 peripherals with the MCLK > ULPCLK , errata condition occurs  or Is it both parallel CPU write / CPU read access to PD0 peripherals that can cause issue. 

  • Hi Jayakrishnan,

    Let me check if the errata will also affect writes on the peripherals.

    Regards,
    Luke