Left microphone not working with ADAU1761 headphone implementation

Hello Orpheus,

This sounds very much like a timing issue with the PDM clock and the returning data. This is also Signal Integrity related as well.

Since you are running at 1.8V the drive strength for the clock outputs is weaker. This causes the rise time of the clock edges to be slower. So the clock has to travel to the mic, then the mic has to output a high or low on the edge of the data that it is set to use. Then the data has to travel back to the DSP. So I am guessing this is what is causing it. The data is arriving back too late.

Keep in mind that as you add length to the cable you add capacitance which slows down the clock and data edges even more.

You did not show scope shots at different places of the clock and data to prove this so I am just guessing.

I do not have a lot of suggestions.

The timing for a PDM signal is very important and I am not sure if you add a buffer with more drive strength if that might help. Every device will add some propagation delay. You may need two buffers, one on each end possibly but again, buffers are not a good idea.

Perhaps try a lower capacitance cable at least as a test to verify that this is the problem?

You said you did look at the far end. What you need to look at is to trigger a scope from the clock at the DSP side and then look at the data line at the DSP end and compare the edges of these two signals.

Dave T

Hey Dave!

So we made some tests to see the signal, if there was a problem with the clocks and/or data.

From what we got it seems to actually be fine, both microphones have the same clock signal and the data signal is extremely similar.

This is how the data signals looks like, the red has a little more noise (but we thought that it was not the source of our problem):

These are the clock signals, they look identical:

and this is the clock signal with the data signal.

One other thing we notice is that, even though in the Sigma studio we have the left microphone routed to the left speaker and the right microphone to the right speaker, when we program our ADAU the right microphone goes to both speakers, so we also thought maybe it could be physical problem with how the microphones are connected in the PCB. What do you think?

Kind regards.

Hi again Dave, I shall add to LYNllow comment that:

1. The two clock signals that look identical in the same snapshot are two points measured at the same time, one point at the ADAU and the other at the problematic microphone terminal all the way after the wire;

2. The two data signals that look identical in the same snapshot are two points measured at the same time, one point at the ADAU and the other at the problematic microphone terminal all the way after the wire;

3. The snapshot with both the clock and the data signal are measured at the same time, whether at the ADAU or at the microphone terminal, they looked the same.

4. The last part of the explanation that LYNllow explained is that, with the same sigma studio project on the dev board (which absolutely works) and on our headphone PCB, on the dev board we have the correctly routed output we designed, which is the left mic to the left speaker and the right mic to the right speaker; However, on the headphone PCB, our output is so that the left microphone is always quiet no matter what, and the right microphone is routed to BOTH speakers! Hence we're thinking, could this be a routing problem?

5. Our microphone voltage bias supplied to the left microphone is measured to be 1.64v (which is close to the margin voltage limit of 1.62V according to the datasheet of the mic).

Cheers!

Hello Orpheus,

We took a good look at your screenshots. Thanks for taking them. First, I think you are using a 10X probe and the scope is not set for a 10X probe. The voltage levels are really low, less than 200mV. But if you multiply by 10 then it is less than 2V which makes more sense and it is working so this is a scope setup issue. So moving past that...

The clock waveforms look good. The data looks good but it appears that the data is only changing in time for the rising edge. We see no transitions in the middle of the clock when the clock is high. So we are thinking this is because either one of the mics is not transmitting at all or both mics are set to transmit on the same clock edge. There will be a pin to setup the mics to drive the left or the right. They seem to be setup the same or one is just not working?

In a PDM mic system one mic will drive one edge, the other mic drives the other edge. So a microphone output drive is only on for one edge and is tri-stated for the rest of the time. So what happens if there is nothing driving the other edge then the bus is floating. It will stay high for a fair amount of time. So when the left channel drives a high it stays there for a much longer time than one edge and so the mic signal is picked up by both channels. So having the same signal on both will tell you one mic is not driving the bus.

Dave T

Hi Dave, Thanks a lot for your helpful replies.

Yesterday to be sure that what you're saying is aligned with what we observe, we measured the same signals shown above on the devboard (with the exact same sigma studio project) and it's exactly as you're saying - we can observe the mic data shifting 0-1/1-0 after both rising and falling edge of the clock - but we can only observe data shifting after rising edge with our PCB.

New finding: we've noticed that in the adau 1671 devboard datasheet figure 14, both the BCLK and the SELECT schematics are populated with resistors:
1. SELECT is populated with resistors R36 and R37 before going to VDD or GND, and,
2. BCLK has a resistor R48 connected to both mics.

I'm sorry I didn't bring this up, this is a difference that we only detected now - we were wondering if this could be the reason, because our designer didn't follow this schematic, he followed the schematic from the microphones itself (IM69D130), which has some slight differences.

Cheers!

Hello Orpheus,

The resistor on the bit clock, R48, is a 100 ohm resistor. It is a damping resistor so it is good for it to be there. It is a little high and might be better with 11- 33 ohms. Without a full signal integrity analysis it is difficult for me to say what it should be but I do not think this is the problem.

R36 and R37 might be an issue. 10K is a little on the high side for a pull up or down and usually is not a problem. I looked at the IM69D130 datasheet and it just shows these lines tied directly to ground and VDD so this might be the issue. It depends on what is inside the part. So since they show it directly tied it is reasonable to replace these 10K resistors with zero ohm jumpers. That is worth doing as an experiment. It would fit the symptom that both mics are driving the same edge and these resistors are responsible for setting the drive channel.

For others who might be reading this, here is a diagram of a PDM signal in relation to the clock. You can see the data change time is when the clock is high or low and must be stable by the time the edges arrive. One channel drives the rising edge and the other the falling edge. They share the same data line. So with two mics getting slightly different audio the output will not always be exactly the same. It will be the same many times but not always. So you will see some transitions when the clock is high because one channel needs to be high and the other low. The same applies when the clock is low. In the cases where one channel was high and the other needed to be low you will see a change on data line when the clock was low. Since in the screenshots we only saw changes when the clock was low it shows a possible issue with the other channel. It is good to cover up one of the mics to try to make the data more different so you can see the other channel's data more easily.

Dave T

Hey Dave,

Thank you very much for your answer, it was very clarifying and we are going to try to implement these changes and see if it will fix the issue.

On another note, we are having some problems booting the DSP through our microcontroller. We have a program data with 3150 bytes, normally we would do a burst write and write everything at once, but we have little RAM memory on our microcontroller so we can't do that without crashing it, so I was trying to write 255 bytes at a time for the program data but this is not working for some reason. I saw on the datasheet that the registers on the program data are 5 bytes long, so I'm taking that into account to get the register address for the next 255 bytes. Do you have any idea what can be wrong? Is it not possible to write the program data separately?

Kind regards.

Just a heads up Dave, we solved the latest issue on the booting problems ;)

We didn't solve the microphone problem yet, but we're on it.

Have a lovely weekend!