GIMA, I2S, Timer not counting correctly

[lpcware]

Content originally posted in LPCWare by ArriaLive on Mon Dec 08 11:08:45 MST 2014
I have spent many hours trying to debug this, but perhaps I am missing something.

I have configured I2S1 on the LPC4330 to follow the audio clock generating a wordclock of 48kHz.  This is verified with an oscilloscope.  But the specific rate coming off the I2S port is not the issue.  I am trying to count the number of words transferred based on the wordclock (I am using DMA to actually move the samples).  According to the documentation, I should be able to connect the I2S1_RX_WS signal to TIMER2 routing the signal through the GIMA.  When I do that, I should have something like this:

BASE_AUDIO_CLK -> I2S1 -> I2S1_RS_WS -> GIMA -> TIMER2 (see attached image).

This all seems to work except that the counting is incorrect.  In one case, I am trying to count 19200 samples, which should result in an interrupt from the TIMER at 2.5Hz (The GIMA divides by 128, and the TIMER is configured to count to 150, then interrupt).  However, the interrupt occurs about every 2.34Hz, after the I2S1 has only transferred about 18400 samples.

I2S1 is transferring correctly and has been verified.  Using DMA, I have verified the counts.  When TIMER2 interrupts, the TC is exactly 19200, even though I2S has only clocked out about 18400 samples.  So, somewhere in the GIMA or TIMER2, the timer is overcounting about 1 in every 16 clocks.

Can anyone tell me why that is?

Thanks,

[lpcware]

Content originally posted in LPCWare by ArriaLive on Fri Dec 19 12:58:06 MST 2014
I see that I did not get any replies, even from NXP.

I tried a different approach with this, taking the BASE_AUDIO_CLK signal through an SGPIO (rate verified), then through the GIMA to the state-controlled timer (SCT).  I have verified that some signal is getting through to the SCT, and when I change the BASE_AUDIO_CLK frequency, the SCT changes as well, so I know they're connected.  However, I cannot make heads or tails out of the frequency coming into the SCT.  It simply isn't right.  It clocks at about 3.48x the expected rate.  Not 4x, which might be a configuration problem, 3.48x.  Where does that come from?  I divided the signal by 4 just to see if that would work, but of course it remained off by about the same percentage.

Given this experiment, and the one above, and given that no one else seems to know anything about the GIMA, or even use it, I have to assume that the GIMA simply doesn't work.  In each case, I'm getting values that are 6-10% off what is expected.  If I'm missing something, someone tell me, but after several days experimenting each path, the results appear to point to errors in the GIMA.

NXP, or anyone else, can you provide a demonstration--using the audio clock as an input--that proves my conclusion wrong?