TMS320F28335: DMA/CPU conflict

Hi Shivananda Bairy,

From what you have mentioned here, there could be multiple reasons why you might be seeing the irregularities in the number of times the two interrupts are being serviced. Following are some of the directions in which you could look to further debug the issue:

1) Are you acknowledging only group 6 in the McBSP ISR? (Just make sure you don’t acknowledge group 7 as well in the same ISR. This should be done in the DMA ISR).
2) Since you mentioned that there is no issue if you remove all other functionality except for the DMA and the McBSP receive, check how frequently the McBSP ISR is getting serviced and how long it takes for the CPU to service this ISR? (If it is too long when compared to the DMA transfer, and if the DMA has continuous mode enabled while the McBSP data is received continuously, then there will be DMA interrupts which could be missed while the previous DMA interrupts might have been pending to be serviced.)
3) Once the McBSP ISR is received, Make sure that data is being sent out to the LS7 SARAM through DMA before accepting any new data on the receive buffer?
4) Also, irrespective of the number of interrupts received by the DMA, Check if the data integrity is intact in the LS7 SARAM. (Check if the data received at the DMA destination is as expected.)

Thanks & Regards
Pramod P

Hi Pramod P

Thanks for the immediate reply.

1. Only Group 6 is acknowledged in McBSP ISR, and Group 7 is acknowledged in DMA ISR.
2. I'm not using continuous mode in DMA. So, the McBSP ISR just contains DMA channel reset for the next transfer. This should not take much time.
3. DMA channel is coupled to the REVT from McBSP. So, when new data is received, DMA must be able to transfer the data from DRR to L7 SARAM before the next data is received. The exception can be, if the DMA is stalled because of some conflict of the interface with CPU.
4. Data in the DMA destination is as expected.

When I told, I removed other functionalities, I just removed some CPU intensive calculations (FIR filter from TI FPU library and some arithmetic & trignometric algorithms), but all the other hardware specific functionalities were still running. Is there any specific CPU instruction which stalls DMA..?

Regards,
Shivananda Bairy

Hi Shivananda Bairy,

Ok. From what I understand this is happening because of the CPU Bandwidth being limited for your application. Can you please try to put some GPIO toggles for each of the two ISR’s and do a profiling with the full application and after removing the functionalities(FIR filter calculations etc). This should give you an idea on how much exactly the CPU bandwidth these ISR’s are getting.
Check the MIPS you need for your application and that should help you determine if this device can support it.

The only contention is when both CPU and DMA simultaneously access the same memory interface which is not true in your case. CPU will win the arbitration in such a case.

Thanks & Regards
Pramod P

Hi Pramod P,

These two ISR's execute every 1millisecond. I have done the profiling of these ISR's with and without other algorithms and results are same for both the cases.
McBSP ISR: maximum 3 microseconds
DMA ISR: maximum 200 microseconds with average of 40 microseconds.
And the overall CPU load of the application calculated from the idle task is less than 50%.

As the other algorithms run in an RTOS Task and has less priority than the ISR's, I don't think it's the problem of CPU bandwidth. I replaced the algorithms with equivalent delay function (DSP28x_usDelay()), the ISR's run perfectly without any miss.

Yes, there should not be a conflict because there is no other data in the L7 SARAM and CPU only accesses this I/F inside the DMA ISR to copy the data to other buffer. Even if there is a conflict, as per the datasheet, DMA has higher priority. I'll look inside the algorithms, if any particular function is causing this issue.
Thank you,

Regards,
Shivananda Bairy

One correction in the above reply,

4. Data in the DMA destination are sometimes misaligned.

Ok. That makes sense. Looks to me like you have an issue with some triggers which fails to be honored by DMA. The McBSP is triggering the DMA way too fast I believe. This aligns with the observation of the time it takes for the DMA to start the next iteration (large difference between the execution times of the ISRs.)

Please tweak around to align the timings of the McBSP DMA triggers in your algorithm.

Other thing to do is to check your algorithm like you mentioned above to see if there is any kind of access going to same interfaces which affect the timings and thereby resulting in the conflicts between the two masters.

Hope this helps you to resolve your issue. Let me know if not.

Thanks & Regards
Pramod P