Rune,
BSP usually means Board Support Package. I have to assume you are talking about the McBSP, the Multi-Channel Buffered Serial Port on the C6746; is that correct?
[quote user="Rune Knutsen"] From time to time the BSP fifos underrun/overrun. This seems to be related to (multiple) L2-cache line fills.[/quote]
How have you come to decide that the underrun/overrun is related to L2 cache operations?
[quote user="Rune Knutsen"]- Will EDMA access to L2-SRAM be stalled for the complete L2-cache line fill period?[/quote]
L2 Cache operations will cause read or write commands to be sent out through the C674x Megamodule's MDMA port. EDMA access to the L2 SRAM go into the C674x Megamodule's SDMA port. All memory bus operations are commands that start and then allow other memory commands to work in-between them. The bus architecture of the device is such that multiple operations will go on simultaneously unless they are to the same endpoint; if to the same endpoint, then they will interleave with each other in burst sizes defined by the bus master driving the operation.
There is an issue listed in the C6746 errata document about stalls occurring when the DSP and the EDMA have the exact same priority. Please check this and make sure you are following the workaround(s) suggested.
[quote user="Rune Knutsen"]- Is there any way to prevent CPU accesses to increase in priority, but always stay below EDMA in priority?[/quote]
It is usually not a good choice to slow down the DSP in order to let peripherals run faster. The intent of the EDMA is to relieve the DSP from having to do the data movement in the first place. But there are priority settings that can be changed. See the C6746 Data Manual for the SYSCFG module, and then look to the TRM for more information. To address the errata Advisory 2.3.1, you could set the EDMA priority to a higher number (lower priority).
[quote user="Rune Knutsen"]- It seems to help if I increase EDMA burst length. My guess is that there will be a arbitration between L2-cache line fills and EDMA accesses and that the more the EDMA can do in each burst, the more that it will transfer between L2-SRAM and BSP fifos. Is this correct?[/quote]
This does sound like one of the valuable efficiency points to consider with the EDMA and McBSP.
[quote user="Rune Knutsen"]Do you have any advice for how solve this problem apart from putting in a faster external memory?[/quote]
There is a lot of guessing for us to do because of missing information:
- How fast is your McBSP running?
- How fast is the DSP being clocked?
- How is the data configured in terms of bits per data item?
- How much is the EDMA reading/writing per FIFO event?
- What is the data size being accessed by the EDMA?
In situations where EDMA bandwidth is failing to meet the real-time requirements of a peripheral such as the McBSP, there are several "knobs to turn" or things that should be considered to keep the DMA transfers efficient and timely:
- Access data at the McBSP as 32-bit wide data. If the native data in/out is 8 or 16 bits, consider configuring the McBSP to naturally concatenate the data into 32-bit words, if this can work with your FS requirements at the pins. This will minimize the number of accesses to the McBSP buffers. It may be best to do this for the McBSP accesses, and then split the data into 8 or 16-bit buffers using another DMA channel once per large buffer transfer (144 samples or such).
- Use the FIFO at its mid-point to buffer up as much data as possible before starting a transfer. This is probably what you were talking about when you mentioned increasing the EDMA burst length.
- If the conflicts appear to be with L2 SRAM being the DMA endpoint, consider using the 128KB Shared RAM to avoid these conflicts. You have trigger another DMA channel to move data between L2 and Shared RAM once a full buffer's worth of data has moved in or out.
Regards,
RandyP