zybo Zybo: SSM2603 Audio chip stays silent even after initialization

[bajelly]

After trying about everything I could think of, I am still not able to produce any sound through the DAC on the Zybo's audio chip.

I tried initializing the chip via I2C using what I think are the proper register values and the proper power on sequence, both using a core I wrote myself, and alternatively by connecting the I2C interface through to the Processing System and using Linux and i2c-tools there to set the register values from the command line. My initialization sequence includes activating the digital core (R9), enabling the DAC by setting DACSEL, unmuting the DAC, powering on both before (without Out) and after (with Out) setting the other registers and with the proper delay, and many more things. I am also pulling the active-low MUTE pin high using "i2c_m_mute <= '1';" in VHDL.

I can make the chip pop and hiss by powering it on, and I think I can manage to put Line In or Mic onto the output with the right register values (not entirely sure since I had no Mic laying around, but I'm relatively sure I heard something when I improvised with some ear buds). Overall, there's strong indication that my initialization sequence is at least partially successful, but the DAC remains entirely silent.

For the I2S signals, I have a 12.288MHz MCLK fed by a Clock Wizard, a 48kHz PBLRC clock, a 3.072MHz BCLK (for 64 cycles per 48kHz sample, but I also tried using half of that since I am only trying to feed 16bit data) and PBDAT aligned to that. I verified both with an ILA core and with an oscilloscope directly at the chip pins that the signals are there and look sound.

Yet I cannot even make the chip produce anything digitally. Even if PBDAT is screwed up, it should at least produce some sort of random noise or clicking, no?

What am I missing? Since I'm very new at FPGAs, this may be something entirely obvious.

 

Attached is an example of what is going on on the I2S wires. I tried at least left justification and the I2S format. This is with a BCLK for 32 bits per sample (i.e. 16bit per channel), as mentioned above I also tried using a 64bit BCLK with no effect.

 

[JColvin]

Hi bajelly, 

I personally don't know the answer to your question, but I would recommend checking out this other thread on our forum where it seems that a user was able to get the Audio Codec working for the Zybo with petalinux.

Let us know if you have any any more questions.

Thanks,
JColvin

[bajelly]

Thanks. I already found that thread, but I don't think it's completely related. The thread mainly talks about how to get the audio chip working with Linux. In my case, Linux is not relevant at all, everything is done from the PL. In fact I'm trying not to use the Processing System at all, the only time I did was to use i2c tools from Linux to directly set the registers that way, as a debugging help. Any Linux drivers are not involved.

Basically my question simply boils down to: What, exactly, do I need to do to actually use that chip's DAC to produce some audible sound?

I am almost beginning to suspect that the chip might be broken... but it's probably just my fault.

 

[D@n]

A PL only solution?  Without Linux?  Sounds like my kind of problem. 

Let's start at the top: the chip is I2C configured.  1) Are you able to tell if the chip "ACK"s your register writes?  2) If you read back registers that you've configured, can you tell that you've configured it?  In other words, if you change a register, can you then read the register and tell that the changes you made to it had the proper effect?

Moving on to I2S, there are a couple of common problems I've seen/had with just about every audio system I've tried to program.  The first is byte order, the second is bit order, although signed versus offset format can get you too.  The fact that you can hear "clicking" noises could be related--although most common a "clicking" noise is what you hear when you power a device on or off.  But, hey, let's see if you are writing anything to the device.  Can you send a "tone" of some type to the device?  Let's pick a 16 bit value of all zeros, and then pick one bit to swap at, oh say, 440 Hz.  This should produce a nasty buzzing sound, but at a known frequency--such as the tuning "A" above middle "C" (440 Hz).  Hence you could try sending alternating 16'h080 with 16'h000 and listen to the result.  Anything?

I'm assuming you have a copy of the spec for the chip, right?

If you are interested in example code, I know of example I2S and I2C code you might find valuable ... although I haven't tried them myself, so I cannot vouch for them.

While it is possible your chip is broken, I'd hate to jump to that conclusion too early.  Do you (or anyone else) know if there is a demo Zybo program that you can use to prove that the audio chip is working?  That's usually the way to figure that one out--if the demo doesn't' work, then you've either got your device miswired or it truly doesn't work.

Dan

 

[bajelly]

18 minutes ago, D@n said:

A PL only solution?  Without Linux?  Sounds like my kind of problem. 

Much more fun

 

18 minutes ago, D@n said:

Let's start at the top: the chip is I2C configured.  1) Are you able to tell if the chip "ACK"s your register writes?  2) If you read back registers that you've configured, can you tell that you've configured it?  In other words, if you change a register, can you then read the register and tell that the changes you made to it had the proper effect?

I am pretty sure my I2C logic actually works. I latch any ack failure on an LED and I've looked at the signals through a logic analyzer core in detail.

Also, at some point I was so desperate that I instead connected the I2C signals to the PS, and used I2C-tools to set the registers from the command line.

I will double check again...

 

18 minutes ago, D@n said:

Moving on to I2S, there are a couple of common problems I've seen/had with just about every audio system I've tried to program.  The first is byte order, the second is bit order, although signed versus offset format can get you too.

Hmmm. But even if I messed that up, shouldn't I at least get something? In theory, random data should contain energy across all frequencies of the spectrum, no?

Unless I was so unlucky that in every try where I got the register values right, I somehow messed my 2kHz tone up in a way that shifts it to inaudible frequencies...

Actually, maybe I should produce random data instead of a 2kHz tone, that's more unlikely to be messed up completely inaudible!

18 minutes ago, D@n said:

The fact that you can hear "clicking" noises could be related--although most common a "clicking" noise is what you hear when you power a device on or off. 

Nonono, I am actually pretty sure the clicking and hissing I hear is only attributable to powering the device on and routing the analog inputs to the output... Literally nothing changes if I turn my data stream off, so I think my digital data is completely inaudible.

 

18 minutes ago, D@n said:

But, hey, let's see if you are writing anything to the device.  Can you send a "tone" of some type to the device?  Let's pick a 16 bit value of all zeros, and then pick one bit to swap at, oh say, 440 Hz.  This should produce a nasty buzzing sound, but at a known frequency--such as the tuning "A" above middle "C" (440 Hz).  Hence you could try sending alternating 16'h080 with 16'h000 and listen to the result.  Anything?

I started out with a 2kHz WAV that I put into a ROM IP Core in my design. I messed actually putting that down into samples a lot, but deliberately because I only wanted to hear something for starters, and fix my LR multiplexing up later.

But I literally hear nothing.

 

18 minutes ago, D@n said:

I'm assuming you have a copy of the spec for the chip, right?

I think I could recite it in my sleep by now 8)

 

18 minutes ago, D@n said:

If you are interested in example code, I know of example I2S and I2C code you might find valuable ... although I haven't tried them myself, so I cannot vouch for them.

Anything helps!

Though the sample initialization code that I saw and that is supposed to work on the Zybo doesn't really do anything different from what I do...

 

18 minutes ago, D@n said:

While it is possible your chip is broken, I'd hate to jump to that conclusion too early.  Do you (or anyone else) know if there is a demo Zybo program that you can use to prove that the audio chip is working?  That's usually the way to figure that one out--if the demo doesn't' work, then you've either got your device miswired or it truly doesn't work.

That is actually a very good idea. I will try to get some demo project working and see if it does anything.

If not, my chip is toast. If it does work, I can see if I spot any difference in the initialization or the I2S logic traces...

Thanks so far!

[D@n]

Okay, we're getting closer then.  Here's a couple more questions:

1. If you place the device into record mode (master I2S), can you get it to produce the BCLK signal?  If so, what frequency is that BCLK signal at?  (Measure the number of clock ticks, or example  between rising edge and rising edge ...)  Does it match the BCLK signal you were producing?  Can you change the frequency of that signal by changing the sample rate?

2. What about the bypass mode?  If you place the device in Bypass mode, can you hear audio from the input line showing up in the output line?

3. You said you were pretty sure that I2C interface woked ... let's just double check.  If you write a register, and then read back its value, do you get the new value back?  Does this work for all of the bits in a register?

As for the 2kHz audio, yes, that should work, but ... if you don't mind, I'd rather not be in the room when you test it. 

Yours,

Dan

[hamster]

Oh, one thing to be careful of is that I2S samples are signed, so don't test with alternating between 0x0000 and 0xFFFF  (0 and -1) as it will be very quiet, 0xC000 and 0x4000 are a better option for first tests. These values do however these values make perfect test values for verifying the alignment of the data vs the LR clock

And why we are on the subject, I2S comes with a few different options for the alignment of the first bit of the same to the edge of the LR clock, and the justification of the samples within the frame (e.g. does the padding proceed or follow the sample values).  

I've got something that generates a valid I2S stream here: http://hamsterworks.co.nz/mediawiki/index.php/PMODamp3 - you might want to simulate it and see if it matches your implementation.

[bajelly]

Thanks for the suggestions and explanations. As soon as I have time for it, I will try to get an existing project running to confirm that the chip is indeed working and to look at the signals if it is. I will also double check that my I2C initialization does work, by reading back the registers.

Other than that, does my approach to try to dump some pseudo-random data (using an LFSR for example) be a viable way to see if I can make the chip produce some sound? The theory behind this is that even if I really mess up slicing the data into samples, as long as it still produces random-ish samples there should always be some very audible sound in (theoretically) all of the frequency spectrum.

While with a tone, it's somewhat easier to accidentally produce an inaudible signal (e.g. using 0x0000 and 0xFFFF which hamster just mentioned).

[sLowe]

Hey Bajelly,

Your random values idea should produce some audible static. Unfortunately I don't know of any non-linux audio codec examples. We had a lot of fun figuring out the codec on the nexys-video for the looper but  that uses a different codec.

Good Luck!

Sam

[bajelly]

To close the loop: I was actually able to solve the problem and now have a small IP Core that initializes the sound chip and sends samples (latched in via the simplest bus, should be compatible to AXI4 Stream) to play them. All in the FPGA fabric, without any external support needed, so that's neat.

Unfortunately, I don't really remember what the problem was. I changed the initialization sequence a bit to be closer to a (microprocessor) example that I found online and it started working. It was a bit puzzling, though, since what I did seemed perfectly legal according to the data sheet.

If there is some demand, I can clean up the code and put it up online, in case you want to play sound without microprocessor support.

[sLowe]

Id love to see your project! Also @Axe may want to take a peek at your non microblaze project too!