• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 82 subscribers
  • Views 276 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.

TMS320F28388D: FSI RX DMA with single DMA channel

Jesse Leonard
Prodigy 90 points

Part Number: TMS320F28388D
Other Parts Discussed in Thread: C2000WARE

I'm working with F28388D as an FSI Lead and F280039C as FSI nodes in a daisy-chain configuration similar to the FSI daisy-chain application note. 

I have the 8 FSI RX channels split equally across the two F28388D CPU1/CPU2 cores (each manages 4 FSI RX). I had success with the FSI RX DMA c2000ware example using 2 DMA channels for the FSI RX - 1 for the TAGUDATA and 1 for DATA. Using 2 DMA channels per FSI RX channel, I'm running into a limitation with number of DMA channels per F28388D CPU (6 channels per CPU), and can only handle 3 FSI RX channels instead of 4.

 

Is it possible to move an incoming FSI RX data packet TAGUDATA (1 word) and DATA (16 words) using a single DMA channel with a single burst from the FSI RX trigger?

My fundamental problem is that the FSIRX_TAGUDATA register is not adjacent to the FSIRX_DATA in memory. The C2000ware examples solved this by using two DMA channels, one for TAGUDATA and one for DATA. But that limits you to 3 FSI RX since there are only 6 DMA channels.

Looking at the FSI RX memory map, Table 32-40. FSI_RX_REGS Registers of F28388D TRM,
RX_FRAME_TAG_UDATA @ 7h offset
RX_BUF_BASE_y @ 40h + formula offset

to try and move everything from RX_FRAME_TAG_UDATA all the way to the end of RX_BUF_BASE_y would require moving 72 uint16 words, which is beyond the DMA capability - even using 32bit words within a single burst, num within a burst is limited to 32, i.e. 64 uint16's. (not sure that works either since the 28388D TRM still shows max of 32 16-bit words max per burst in Table 11-2. BURSTSIZE versus DATASIZE Behavior.

Is there a workaround for a single DMA to move the RX_FRAME_TAG_UDATA @ 7h (one word), then source_addr skip to the RX_BUF_BASE_y @ 40h (16 words, burst_step = 1) to move 17 words total in a burst from a single FSI RX trigger?

Or to setup a space in memory where FSI RX TAGUDATA and DATA are adjacent so the DMA source_addr can simply increment by 1 (burst_step of 1 address)?

Regards,

Jesse

 

  • 0
    TI__Mastermind 28580 points

    Hey Jesse,

    I'll get back to you tomorrow on this, will need to consult with the DMA expert on our team to understand if this is possible.

    Thank you,

    Luke

  • 0 in reply to Luke Jones
    TI__Mastermind 28580 points

    Hi Jesse,

    Have you considered using the CLA specifically for the TAGUDATA and using the same FSI event to trigger the CLA to move this value in parallel with the DMA moving the 16 words? There are up to 8 CLA tasks, so you could have one CLA task per FSIRX channel on the device in total.

    Jesse Leonard said:
    Or to setup a space in memory where FSI RX TAGUDATA and DATA are adjacent so the DMA source_addr can simply increment by 1 (burst_step of 1 address)

    The above seems feasible as well. Would this be a packet of 17 usable bytes in your case?

    Thank you,

    Luke

  • 0 in reply to Luke Jones
    Prodigy 90 points

    Hi Luke,

    Originally I was servicing the FSI RX data packets with FSI_Interrupt1 on CPU1/CPU2 respectively and it was handling traffic for one FSI RX channel fine. Once the control loop interrupt started to expand and adding more FSI RX channels, the FSI RX INT1 was getting behind and I started getting buffer overruns and missing packets.

    The two solutions I came up with was move everything to the CLA, basically 1:1 transfer of FSI RX INT1 on CPU1/CPU2 and move to the CLA. The other was with the DMA. I have more experience with the DMA so I went that route, I haven't worked through the CLA examples yet. If I can get the DMA to work with 1 DMA channel per FSI RX channel I'd prefer that route.

    The hybrid approach you bring up of DMA for the FSI RX DATA and CLA for FSI RX UDATA is interesting but it looks like it would have to split RAM spaces, am I recalling correctly that CLA/CPU needs to use LSRAM and the DMA is only connected to GSRAM? So the FSI RX DATA would have to be on GSRAM for DMA, and the FSI RX UDATA would need to be in LSRAM for CLA?

    Luke Jones said:
    Jesse Leonard said:
    Or to setup a space in memory where FSI RX TAGUDATA and DATA are adjacent so the DMA source_addr can simply increment by 1 (burst_step of 1 address)

    I'm familiar with the memory mapped peripherals and the Table 32-40. FSI_RX_REGS Registers of the F28388D TRM. Is it possible to re-map these so that RX_FRAME_TAG_UDATA is adjacent to RX_BUF_BASE_y? That would be a very clean solution for the 1 DMA channel to move FSIRX UDATA and FSIRX DATA. How exactly would remapping, or adding a secondary alternate map (so the original addressing isn't broken)?

  • 0 in reply to Jesse Leonard
    TI__Mastermind 28580 points
    Jesse Leonard said:
    So the FSI RX DATA would have to be on GSRAM for DMA, and the FSI RX UDATA would need to be in LSRAM for CLA?

    I believe so, I understand that might be inconvenient.

    In my opinion the pure CLA approach would be the cleanest solution if you don't need CLA for any other purpose, but understand this is extra work since you've gone down the DMA route already. I can reassign this thread to one of our CLA experts to assist with the implementation if you eventually decide to use CLA.

    Jesse Leonard said:
    I'm familiar with the memory mapped peripherals and the Table 32-40. FSI_RX_REGS Registers of the F28388D TRM. Is it possible to re-map these so that RX_FRAME_TAG_UDATA is adjacent to RX_BUF_BASE_y? That would be a very clean solution for the 1 DMA channel to move FSIRX UDATA and FSIRX DATA. How exactly would remapping, or adding a secondary alternate map (so the original addressing isn't broken)?

    I am looking into this, I will get back to you.

    Thank you,

    Luke

  • 0 in reply to Luke Jones
    TI__Mastermind 28580 points

    Hi Jesse,

    From reading the TRM and analyzing our FSI drivers it seems that RX_FRAME_TAG_UDATA is always at a fixed address unlike the configurable RX_BUF_BASE_y register.

    Thank you,

    Luke