• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 257 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.

TMS320F28335: The workflow of DMA,MCBSP in demo code "mcbsp_loopback_dma"?

li xy
Intellectual 355 points
Part Number: TMS320F28335
Other Parts Discussed in Thread: C2000WARE

Hi all:

    The demo code I used is "F:\C2000_SDK\C2000Ware_1_00_03_00\device_support\f2833x\examples\mcbsp_loopback_dma". I have changed the working mode of MCBSP from loopback to clockstop mode and it works well.

    The  next step is to test DMA function. However, I have some questions:

    1. The dma needs trigger so that in demo code, the trigger sources are "DmaRegs.CH2.MODE.bit.PERINTSEL = DMA_MREVTB;" and "  DmaRegs.CH1.MODE.bit.PERINTSEL = DMA_MXREVTB;"

          1.1 During the transmitting process, the DMA should move "Sdata[]->McbspaRegs.DXR1.all", but how MVBSP trigger the DMA? When "Sdata[]" has been filled fullly, then MCBSP will trigger the DMA to move ?

          1.2 During the receiving process, the DMA should move "McbspaRegs.DRR1.all -> Rdata[]", but how MVBSP trigger the DMA? As soon as the "McbspaRegs.DRR1.all" has val, then trigger the DMA to move?

   2. There are two DMA interrupts in demo code and are for DMA channl1 and 2. The function of them is just to check the correction after moving.

       2.1 The trigger source of DMA is MCBSP, so is this trigger source called MCBSP event?

       2.2 Do these two DMA ISR occupy CPU resources?

  3. The whole process in my mind is:

     3.1 fill the Sdata[] -> then  DMA_MREVTB trigger DMA to move Sdata[] to "McbspaRegs.DXR1.all" reg -> The cpu enter "local_D_INTCH1_ISR", waitting for transmitting done ->  start DMA again by setting 1 to run bit;

    Is anything wrong with this process?

Best Wish

Li

  • 0
    TI__Guru 53895 points

    1. There's a table in the TRM (Table 12-3) that describes the DMA trigger events. The events tied to the DMA are called REVT and XEVT.

    2. Hopefully the table I mentioned about will clear up your 2.1 question. For 2.2, yes, like any ISR, a DMA ISR does take CPU cycles to execute. You don't necessarily have to use the DMA ISR if you don't want to though. You can always just read the DMA flags in the code to see if Rdata is ready to be read or Sdata is ready to be updated.

    3. Yes, you can do that. Just recall that the XEVT occurs when the transmit registers are ready to accept new data which may happen before Sdata is ready with the next set of data you want to send, so you would want to wait until after that to set the run bit again.

    Whitney

  • 0 in reply to Whitney Dewey
    Intellectual 355 points

    Thank you for replying me. I have one more thing to make clear:

    1.The two DMA ISRs are just for DMA channl 1 and 2 but it has nothing to do with two MCBSP events?

  • 0 in reply to Whitney Dewey
    Intellectual 355 points

    Could you please give me an example abour XEVT? I do not really understand "before Sdata is ready with ...",and i need wait.

    Do you mean I need wait until the SPCR2.XRDY=1(READY)?

  • 0 in reply to li xy
    TI__Guru 53895 points
    li xy said:
    1.The two DMA ISRs are just for DMA channl 1 and 2 but it has nothing to do with two MCBSP events?

    The DMA ISRs occur at the end of the transfer. The MCBSP events trigger the start of the transfers (XEVT on DMA channel 1 and REVT on DMA channel 2), and the DMA ISRs are generated when the transfers complete and all the data for that transfer has been moved.

    li xy said:
    Could you please give me an example abour XEVT? I do not really understand "before Sdata is ready with ...",and i need wait.

    XEVT occurs when the data transmit registers are ready to accept the next word. So whenever that signal reaches the DMA, if the RUN bit is set, the transfer will occur. I was pointing out that there may be a scenario where XEVT occurs but the sdata buffer is still contains stale data--like maybe your application hasn't had a chance to add the next transmission to the buffer yet. In the example sdata is initialized before start_dma() is called, so it's not an issue.

    li xy said:
    Do you mean I need wait until the SPCR2.XRDY=1(READY)?

    No, the DMA is triggered when the the transmission buffer is ready to take on more data, so you don't need to worry about it in software. If anything you might need to check that the DMA transfer has completed before updating sdata, either by waiting for the interrupt mentioned above or by checking the DMA channel's RUNSTS bit.

    Whitney