Communication between TPS65950 and IVA2.2 Subsystem using the McBSP2 interface

GoogleGroups
1

Currently I'm trying to send a tone from the DSP to the audio codec so
that I can hear it with my headset.

I use the McBSP2 interface (SLAVE), and the TPS65950 codec(MASTER).
the communication is I2S.
16 bit per word. (Though McBSP registers are 32-bit long), Dual-phase
(( two channels)FRAME_LEN =1, obviously)
What I do it's this:

- Using appropiate drivers the codec gets initialized, namely those
drivers provided with the 2.6 kernel. Thus, in ARM's side I configure
and load the codec, which once initialized and configured, it is
supposed to be ready.
- I'm doing a little test. First in DSP's side I write 240 times 16-
bit data to McBSP2 DXR register. As I've enabled the XRDY interrupt,
it is supposed that when the Trasnmit buffer (XB) exceeds the
THRESHOLD +1 free locations (for me set to 240), it must trigger an
interrupt and thus, it may be captured having configured properly the
INT vector and ISR routine. Once triggered it can continue triggering
because at isr what I do it is to write 240 times two data types:
INT_MAX and INT_MIN, thus, it might be perfomed a square signal of 400
Hz, this is, a tone which can be heard trough the headset.

Sounds a little weird but that's the idea, although what I really want
it is to try that codec works.

- I'm not using the DMA transfer mode at the moment, it's a simple
test. Is it possible to send data at McBSP2 DXR register and expect
that it reaches properly the TPS65950 codec at the rising edge of FSX
signal for one channel and at the falling edge the other channel? I
also poll the XRDY bit before writing to the DXR register.

Any help will be appreciated.
Ignacio

2

- I'm not using the DMA transfer mode at the moment, it's a simple
test. Is it possible to send data at McBSP2 DXR register and expect
that it reaches properly the TPS65950 codec at the rising edge of FSX
signal for one channel and at the falling edge the other channel? I
also poll the XRDY bit before writing to the DXR register.

Assuming you mean that data for one channel is transferred while FSX is low
and data for the other channel is transferred while FSX is high it's
possible. You don't transfer any data on the edges of the FSX signal :slight_smile:

I hope this helped? In case not, please try to rephrase your question, since
I'm not 100% sure I understood it correctly...

Best regards
  Søren

3

Assuming you mean that data for one channel is transferred while FSX is low
and data for the other channel is transferred while FSX is high it's
possible. You don't transfer any data on the edges of the FSX signal :slight_smile:

I hope this helped? In case not, please try to rephrase your question, since
I'm not 100% sure I understood it correctly...

Right, what I mean it's that DXR sends data through Audio Buffer to XB
(whose THRESHOLD I stablished on 240d).
At the main program I initialize the McBSP staff (DSP side) and the
driver of the codec does the same in the side of the ARM.
Once done I first write to DXR register, and, as XB is empty, the
interrupt triggers.
Once inside the interrupt what I do it's to generate a pulse so I can
see it trough the GPIO 133 at expansion pins of the beagle, better
than
doing a printk.

But what I really want it's to trigger continously the interrupt,
thus, inside the interrupt:

1. I set the interrupt threshold bit(10) in the IRQSTATUS register.
2. Write 20 times the SH_MAX value.
3. Write 20 times the SH_MIN value.
4. Write 20 times the SH_MAX value.
5. Write 20 times the SH_MIN value.
6. Point 2 to 5 I repeat them 3 times.
7. By means of this, theoretically, the INTERRUPT should trigger again
and again, shouldn't it?

I think that no matter what THRESHOLD you set, because it'll trigger
surely as the XB buffer gets empty faster than
the time it takes you to fill it up.

On the other side, I continue without knowing if the driver of the
codec gets initialized well, since it handles with some
McBSP2 register and staff. This can probably disconfigure my own
McbSP2 driver.

But what I need it's to give signals CLKX and FSX to my McBSP2!!

I know that all this sounds difficult to understand, so if there are
still doubts, I'll send you the code, maybe it'll be helpful.

Thanks.

4

But what I really want it's to trigger continously the interrupt,
thus, inside the interrupt:

1. I set the interrupt threshold bit(10) in the IRQSTATUS register.
2. Write 20 times the SH_MAX value.
3. Write 20 times the SH_MIN value.
4. Write 20 times the SH_MAX value.
5. Write 20 times the SH_MIN value.
6. Point 2 to 5 I repeat them 3 times.
7. By means of this, theoretically, the INTERRUPT should trigger again
and again, shouldn't it?

I think that no matter what THRESHOLD you set, because it'll trigger
surely as the XB buffer gets empty faster than
the time it takes you to fill it up.

On the other side, I continue without knowing if the driver of the
codec gets initialized well, since it handles with some
McBSP2 register and staff. This can probably disconfigure my own
McbSP2 driver.

But what I need it's to give signals CLKX and FSX to my McBSP2!!

I'm pretty sure you can configure the McBSP using the ARM and then transmit
data using IVA2.2. I don't think it's intended to be used that way though,
but I see no problems doing it. You of cause need to synchronize who
(ARM/DSP) is doing what to the McBSP configuration at which time in order
for the two pieces of code not to disturb/reconfigure each other...

With respect to the actual Interrupt triggering details I can't help, since
it's too long time since I have actually dealt with programming the McBSP
IPs. You can definitely configure it in a mode where you fill in some data,
let the McBSP transfer the data and raise an interrupt, which will let the
process start over again...

The ARM core is able to fill the data in the buffer at a much higher speed
than the McBSP consumes it...

I hope this answer helped - Good luck
  Søren