CS8416 in Software Mode

[eehobby]

Is anyone here using the CS8416 in "Software Mode"?
If so, I have some questions.

I have built a DAC board with the CS8416 and the MAX9850. I have the I2C bus working nicely (connected to a PIC 18F2550) and I can read/write commands to either chip. But, so far - the only sound output is a few clicks.

Please share your init sequence. Here is mine (function I2C_W2 writes 2 bytes on the I2C bus):

r = I2C_W2(RXI2S_A, RXI2S_SADFMT, 0b10000000);	// set audio output port to Master mode
r = I2C_W2(RXI2S_A, I2SDAC_LRCLKH, 0b10001011);	// set Integer mode, DLY, 24 bit
r = I2C_W2(RXI2S_A, I2SDAC_DAUDIO, 0b00001000);	// set I2S data
r = I2C_W2(RXI2S_A, RXI2S_CNTRL2, 0b00000011);	// set GPO-0, red, to C bit
r = I2C_W2(RXI2S_A, RXI2S_CNTRL3, 0b01100000);	// set GPO-1, green, to NVERR

r = I2C_W2(RXI2S_A, RXI2S_CNTRL4, 0b10000000);	// set RUN

a) which of the 16 choices for GPOn best describes if the CS8416 is decoding a valid stream? I have tried the C (channel status) and NVERR, but they are always 0 (so far).

b) I have my CS8416 in Master Mode and the DAC in Slave Mode, does that make sense?

Thanks,
Jake

[rfbrw]

a)AUDIO 1001 Non-audio indicator for decoded input stream.
In order to make the determination as to whether the data is audio (linear PCM) or non-audio (AC3/DTS) the data has to be valid.

[Koen Smeets]

You might want to do a cross check with (part of) my SPI init code.

This is confirmed to work (also by reading status registers, eg the receiver error (0C) register and the version register (7F).

int control4_reg = 0x8b; // 0x8b = coax 1 default, 0xb2 = coax 2, 0xba = coax 3, 0xa3 = opt1, 0xaa = opt2, 
 
void cs8416_init(void) {
 cs8416_rst = 0;     // put device in reset
 DelayMs(1);       // delay 1 ms
 cs8416_rst = 1;     // wake device
 DelayMs(1);       // delay 1 ms
 cs8416_cs = 1;     // enter SPI mode by setting cs high 
 cs8416_write(control4, control4_reg);   // send run state, RXP0 on, RXP2 (not connected on PCB) to TX
 
 cs8416_write(rem, 0xff);       // unmask all receiver error bits
 
 cs8416_write(int_mask, 0xff);       // unmask all IRQ
 
 cs8416_write(sadf, 0b10100101);  // set master mode (1)
                  // OSCLK is 64*Fs (0)
                  // 16-bit resolution (10)
                  // left-justified (0)
                  // MSB on second clock period (1)
                  // sampled on rising edges of OSCLK (0)
                  // right channel when OLRCK is high (1)
 
 
 cs8416_setpdur(1);
 
} //end cs8416_init

You might want to try reading the 7F register (should read 0b00101111 if you have a version E). First argument of the cs8416_write function is the register's friendly name (defined in include file, but you'll recognize from the datasheet).

Now, the trouble I am having is I am not getting anything useful out of the 0x19 - 0x22 (channel status registers, would love to read the sample rate, bit depth from the S/PDIF stream)... Can anyone help, please?

[Koen Smeets]

wrt b) yes, that configuration makes sense

[Koen Smeets]

Originally Posted by Koen Smeets

Now, the trouble I am having is I am not getting anything useful out of the 0x19 - 0x22 (channel status registers, would love to read the sample rate, bit depth from the S/PDIF stream)... Can anyone help, please?

To answer my own query: I managed to read the channel status registers. Problem turned out to be I have LSB/MSB mixed up. Bit depth, BTW, seems to be set to 24 bits all the time, at least in all the sources I have used so far (on board sound card, EMU0404PCIE card...)

Cheers!!

[eehobby]

Originally Posted by Koen Smeets

 
cs8416_write(sadf, 0b10100101);  // set master mode (1)
                  // OSCLK is 64*Fs (0)
                  // 16-bit resolution (10)
                  // left-justified (0)
                  // MSB on second clock period (1)
                  // sampled on rising edges of OSCLK (0)
                  // right channel when OLRCK is high (1)
 
 
 cs8416_setpdur(1);

Thanks for the example. Can you offer any insight on how you choose those init values;
Why MSB on second clock period?
Why right channel on ...?

Also, what does CS8416_setpdur(1) do?

Originally Posted by Koen Smeets

You might want to try reading the 7F register (should read 0b00101111 if you have a version E).

When I read register 7F, I do indeed get 0x2F.

Jake

[Koen Smeets]

Originally Posted by eehobby

Thanks for the example. Can you offer any insight on how you choose those init values;
Why MSB on second clock period?
Why right channel on ...?

Also, what does CS8416_setpdur(1) do?



When I read register 7F, I do indeed get 0x2F.

Jake

Init values are mostly as per I2S bus specs / datasheet of your DAC IC. I believe you are also configured to use I2S, so possibly you should stick to the init values I have?

CS8416_setpdur(1) sets the PDUR bit. For the functionality of the PDUR bit, please search the datasheet of the CS8416. I can't explain it any better than that.

[Koen Smeets]

One more thing that came to mind: I had a situation where my CPU stalled (because of table writes to program memory), effectively violating SPI timing. Result was skipping inputs when cycling through RXP0 - RXP5.

Do post how you are progressing with troubleshooting.

[eehobby]

I have made some progress and got something out of my DAC. The sound is distorted, but recognizable.

Meanwhile I still can't get the GPO LEDs to change. For example the AUDIO bit should be high when a proper SPDIF/PCM stream is detected, but it stays low all the time (although it does flicker a bit when I disconnect the SPDIF input).

[Koen Smeets]

Originally Posted by eehobby

... For example the AUDIO bit should be high when a proper SPDIF/PCM stream is detected, ...

Are you sure? Datasheet says about the !AUDIO pin 15 in hardware mode "When low, a valid linear PCM audio stream is indicated." (an exclamation mark in front of or a 'overlined' pinnname is an active low indicator)

So when valid PCM is detected pin is low, not high. Still doesn't explain the flickering when you disconnect input, though, LED should be solid on. Time to check the electrical connections, then? Or maybe resetting the part in some while loop?...

Good luck!