I have a C6748 system on TI-RTOS 2.0.1.23 that has been working reliably for some while - until I changed it to start writing to an SD card.
Data from an ADC arrives via UPP and is stored into 12ms packets by the UPP's DMA. Packets go into a queue to be processed by an algorithm (usually there is very little wait as the algo runs in a high priority task). The algo generates 12ms output packets (at a higher sampling frequency) and puts them into a queue from where they are output by EDMA3 to a codec, via McASP. Codec and ADC are fully synchronized and so the time the output packets spend in the queue is fairly constant at 20-21ms (somewhere between 1 and 2 packets). The system runs for hours and days and the input and output stay fully in sync. EDMA LLD is v2.12.0.20
Then I added MMCSD drivers from the BIOS PSP 3.0.1.0 and used the mmcsd_sample project to write a test pattern to an SD card. This runs in a low priority task, so as not to interfere with the original processing - or so I thought. Snag is this - when writing 32kb blocks to the SD card with a single call to BlkWrite(), there is a gradual loss of data from the output queue to the codec - each packet spends less time in the queue, until there is none left. The overall data rate to the SD is about 300kb/s. If I write 4kb blocks at the same overall data rate, the attrition is no longer perceptible (although this doesn't mean the problem is fixed, it just might be much less likely to happen or less frequent).
I've been trying to figure out what's happening and it seems the UPP is losing input data. UPP DMA captures 192 ADC samples per line and 36 lines per window, which constitutes one 12ms packet. I've been monitoring the interval between UPP end of window ISRs using Timestamp_get32(), and this is what I see: usually, the interval is 12ms with a typical variation of 2us. Rarely the ISR is delayed by up to 25us, but always the following interval is shorter by the same amount so that tells me the system has caught up. But sometimes, two consecutive intervals are extended by say 100us and 226us. The numbers vary, but the total is always close to 336us, which is the time taken to acquire one DMA line of data. The following intervals are NOT shorter, so the system is not catching up. And every time this happens, the reserve of data in the output queue lessens by the same amount, about 336us.
And at the output end, the intervals between codec interrupts (EDMA complete callbacks) are regular.
So I'm thinking there's a conflict between EDMA3 and UPP DMA. The data going to the codec is only 2 bytes at a time (ACNT=2, BCNT=252, A sync mode) , so that's quick and unlikely to conflict. Data to the SD card is big blocks so I want to be sure it doesn't lock out other activity.
The codec uses EDMA3 instance 0, queue 0 and the MMCSD is set up to use instance 0, queue 1 (so they use different transfer controllers and MMCSD is using the lower priority queue). Burst size is the default of 64 bytes, I think - I haven't changed it.
I've tweaked bus master priorities, raising UPP from 4 to 0, and dropping EDMA3_0_TC1 down from 0 to 7, but it makes no difference.
I'm checking for UPP overflow and underrun errors, but I never see any.
What else can I try?
And why, if the UPP is missing a whole line of data, does it always affect 2 consecutive windows? Could it mean the UPP is missing a STARTA pulse?
I'd really appreciate a few pointers with this please folks.
Roy
