• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 32 subscribers
  • Views 629 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.

UDMA_MODE_STOP RX channel

Yael Oz
Expert 4355 points


Hi,

I'm using Stellaris launchpad LM4F120H5QR with IAR IDE.

I'm using SPI interface (SSI2) with mDMA enabled (channel 12 and 13) to communicate with CC3000 boosterpack.

The issue is that after few good SPI transfers, RX channel does not move to mode UDMA_MODE_STOP.

When I try to read from the RX I receive the previous data which host already read successfully.

It always happens after a specific command I try to send over SPI. The command following will be stuck due to RX channel is not in UDMA_MODE_STOP.

Just to mention, I also working setup with almost the same code (different configuration) with LM4F232H5QD, with no issues.

According to both MCU's data sheet, it looks like mDNA interface is almost the same (beside hardware configurations). Correct me if I'm wrong.

Any specific difference between platforms that can point the reason why is it not working in one and does in other?

Any idea why this is not working?

Thanks,

Yael

 

  • 0
    Guru 86765 points

    Hi Yael,

        Do post your code, so others can check.

    - Kel

  • 0 in reply to Markel Robregado
    TI__Expert 4355 points

    DMA configuration:

    MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_UDMA);
    MAP_uDMAEnable();
     MAP_uDMAChannelAssign( sSpiInformation.sHwSettings.uluDmaRxChannel);
 MAP_uDMAChannelAssign( sSpiInformation.sHwSettings.uluDmaTxChannel); 
    MAP_uDMAControlBaseSet(ucDMAChannelControlStructure);
    MAP_uDMAChannelAttributeDisable(sSpiInformation.sHwSettings.uluDmaRxChannel,
 UDMA_ATTR_ALTSELECT | UDMA_ATTR_USEBURST |
 UDMA_ATTR_HIGH_PRIORITY |
 UDMA_ATTR_REQMASK);
     MAP_uDMAChannelControlSet(sSpiInformation.sHwSettings.uluDmaRxChannel | UDMA_PRI_SELECT,
 UDMA_SIZE_8 | UDMA_SRC_INC_NONE |
 UDMA_DST_INC_8 | UDMA_ARB_1);
     MAP_uDMAChannelAttributeDisable(sSpiInformation.sHwSettings.uluDmaTxChannel,
 UDMA_ATTR_ALTSELECT | UDMA_ATTR_USEBURST |
 UDMA_ATTR_HIGH_PRIORITY |
 UDMA_ATTR_REQMASK);
     MAP_uDMAChannelControlSet(sSpiInformation.sHwSettings.uluDmaTxChannel | UDMA_PRI_SELECT,
 UDMA_SIZE_8 | UDMA_SRC_INC_8 |
 UDMA_DST_INC_NONE | UDMA_ARB_4);
     MAP_uDMAChannelDisable(sSpiInformation.sHwSettings.uluDmaRxChannel);
 MAP_uDMAChannelDisable(sSpiInformation.sHwSettings.uluDmaTxChannel);
     
    mDMA read:
    SpiDisableSSIDMAChannels();
     MAP_uDMAChannelTransferSet((sSpiInformation.sHwSettings.uluDmaTxChannel|UDMA_PRI_SELECT),
 UDMA_MODE_BASIC,
 (void *)&tSpiReadHeader,
 (void *)(sSpiInformation.sHwSettings.ulSsiPort + SSI_O_DR),
 size );
     MAP_uDMAChannelTransferSet(sSpiInformation.sHwSettings.uluDmaRxChannel|UDMA_PRI_SELECT,
 UDMA_MODE_BASIC,
 (void *)(sSpiInformation.sHwSettings.ulSsiPort + SSI_O_DR),
 (void *)data,
 size);
    SpiFlushRxFifo();
    MAP_SSIDMAEnable(sSpiInformation.sHwSettings.ulSsiPort, SSI_DMA_TX | SSI_DMA_RX);
     MAP_uDMAChannelEnable(sSpiInformation.sHwSettings.uluDmaTxChannel);
 MAP_uDMAChannelEnable(sSpiInformation.sHwSettings.uluDmaRxChannel);
     
    mDMA check status:
    mode = SpiCheckDMAStatus(ch); (using MAP_uDMAChannelModeGet)
    
 enable = MAP_uDMAChannelIsEnabled(ch);
 
 if((mode == UDMA_MODE_STOP) && (!enable))
 {
 return(1);
 }
 
 return(0);
     
    Thanks,
    Yael
     
     
     
     
     
     
     
     
     
     
  • 0 in reply to Yael Oz
    Guru 86765 points

    Hi Yael,

         Try setting UDMA_MODE_AUTO instead of UDMA_MODE_BASIC at MAP_uDMAChannelTransferSet(); declaration. Also, review the udma_demo program at stellarisware for reference.

    - Kel

  • 0 in reply to Markel Robregado
    TI__Expert 4355 points

     

    Hi,

    I reviewed udma_demo programm but didn't see there anything that can help me.

    As I mentioned, I have a code working for LM4F232H5QD, just ported it to LMF4120H5QR.

    Setting to UDMA_MODE_AUTO instead of UDMA_MODE_BASIC caused none of the SPI command to pass.

    Any other ideas? Why does the command not cleaned from the RX channel? I can confirm the host has read the command successfully.

    Can I brutally clean the channel ?

    Thanks,

    Yael

  • 0 in reply to Yael Oz
    TI__Expert 4355 points

    Hi,

    Increasing the size of the buffer given for the channel control structures solved the issue.

    I increase this value from 192 (which was fine for LMF4232H5QD) to 300 for LM4F120H5QR and all command transferred successfully.

    In both cases I made sure the buffer is aligned to 1024.

    According to the data sheet the table structure contains source and destination pointers, transfer size, and transfer mode. It doesn't say it holds the data itself.

    Therefore my question, why should it be different between platforms?

    Why does it work with most SPI commands and with one specific (which has over 200 bytes of data) it doesn't?

    How do I determine the minimum size for the channel control structures?

    Thanks,

    Yael

     

  • 0 in reply to Yael Oz
    TI__Expert 6310 points

    Hi Yael,

    Maybe I can help answer some of your questions.

    The uDMA modules in the LM4F232H5QD and the LM4F120H5QR are almost exactly the same. The only substantial difference is that the LM4F232 has more peripherals, so it may have a few more channels for those additional peripherals. The LM4F120 will have "software" DMA channels instead.

    For both parts, we recommend that the uDMA control table is allocated either 512 bytes of space if only primary control structures are being used, or 1024 bytes of space if both primary and alternate control structures are needed. This table doesn't ever contain the actual data being transferred. It just serves as a set of "instructions" or "configurations" for the DMA module for each uDMA channel you are using. The reason we have a fixed recommended size for the table is because the uDMA module will always look for a specific channel's control structure at the same offset. (For example, SSI2TX is channel 13. According to the datasheet chart, that means it's control structure resides in the table at offsets 0xD0 to 0xD8, or bytes 208 to 216)

    The difference in behavior you are seeing might be because you were using a different SPI module on the LM4F232. For example, SSI0 or SSI1 have channel control structures that exist before byte 192 in the control table, so they would have worked just fine, where an SSI2 transfer might have had its control structure corrupted by other SRAM accesses.

    I hope this information helps. If you think what you are seeing is something different from what I've described, let me know. I may be able to help you find the source of the problem.

    Regards,
    Christian

  • 0 in reply to Christian Jolivet
    TI__Expert 4355 points

    Christian,

    Thank you for your answer.

    Yael