Post Go back to editing

ADAU7118: Trouble with channel enabling

Hello. I'm using 4 ADAU7118 (TDM to PCM converters) with a 25-mic array. They are fed by the same BCLK and FS clocks, and use TDM-8.  Channel enabling is handled using the ENABLES register, with bits 3:0. I can get any individual microphone working, if and only if most of the other channels (across all 4 ADAUs?!) are disabled. So, if I'm using ADAU A, and want channels 0 and 1 to work, I can enable bit 0 on ADAU A's ENABLES reg, and they work. I can do this for any other mic pair.

Enabling 2 channel bits (4 channels) also works. Problem: Enabling more than 2 or 3 causes wonky results on some or all channels. Example: Enabling channels 0-1 and 2-3 on ADAU A works. If I also enable channels 4-5, or any channels on a different ADAU, some or all of the data becomes 0 or -1. Note that the enable status of the clock lines (Bits 5:4) doesn't trigger this; just channels.

I'm currently using 32-bit slots, with a 12.288Mhz BCLK, and 48kHz one-bclk-wide FS. Of note, this has occurred with both slot size 24, and 32. I've tried different drive settings both on the ADAU7118, and the MCU driving the FS and BCLK lines, with no effect. Using 3.3v IOVDD, and 1.8v DVDD.

Any ideas to troubleshoot? The fact that the ADAU channels are interfering with each other across different devices is very odd! (Although they do share the same power, ground, FS, and BCLK lines). Thank you



Added voltage used.
[edited by: The Alchemist at 3:55 AM (GMT -5) on 29 Jan 2022]
Parents
  • Hello Alchemist,

    It is not a problem with all of them sharing the same bit clock and frame clock. The 12.288MHz bit clock and 48kHz fs frame clock will produce 8 channels with 32 bits in each channel. So all that is fine. 

    You did not explain what you are doing with the SDATA outputs? What device are you sending this to? Send over a hardware schematic. If you are using one of our eval board let me know which one and how are you wiring the ADAU7118 parts onto the eval board. Pictures also can be helpful. 

    Dave T

  • Thank you. The SDATA output are each going to an (independent) STM32 SAI block.

    I've attached 2 images of the schematic. Note that I've only included one mic set, and the others are identical.

  • Hello Alchemist,

    So this confirms that you are not tying together the serial data lines. ( I have to check the obvious) So why are you getting the data going to 0 or -1? Have a look at the PDM clock outputs from the7118 and look at the PDM data coming back in when you are experiencing the problem. Going to -1 ( full scale negative) means that the PDM data is gone and sitting at a low. This will produce a full scale negative output from the PDM decimator. For the PDM decimator to put out zeros means that the data from the microphone has to be changing with a perfect 50/50 duty cycle and never changing. 

    So have a look and capture the PDM data with a scope. 

    Since there seems to be a lot of illogical things happening, I am wondering if there is a problem with power or ground or both? How long are the power traces and how far from the STM32 are the 7118 devices and how far are the microphones from the 7118? It can be a problem where the microphones lose their settings and are transmitting on the wrong edge or stopping if the clocks are becoming unstable. When I say unstable, I mean large noise spikes on power or ground can cause false triggers. 

    Take a scope and ground the probe close to the STM32 which I assume is close to the regulators. Then scope the ground trace out by the microphones and by the 7118 devices. Do the same with power. There might be a high voltage drop or not a low enough impedance for the power traces. The problem may not necessarily low impedance but too much inductance along the line. This can cause quick spikes from clocks to drop a voltage across this inductance. This may be how the signals from one 7118 is affecting the others. In addition, the more channels you enable the worse it will get. This does follow the symptoms you are seeing. 

    How were the bypass caps on the IOVDD lines connected on the PCB layout? 

    Do you have power and ground planes on that part of the PCB?

    Dave T

  • Thank you for all the info and troubleshooting advice. I'm unable to use an oscilloscope until next week (out of town) - I'll look at the PDM clock outputs, and mic data inputs in various channel-enabled configs once back. And also look at the ground traces near the mics and 7118s.

    Power and ground sound like they could be a problem. IOVDD is connected to a STM32 dev board's 3v3 out. I'll try a different source once back. DVDD is connected to a 1v8 regulator powered by IOVDD. There are unbroken IOVDD and GND planes under in the middle 2 layers of the entire board.

    The power traces to the ground plane are short, and the ground plane distances to the power pins range from 25mm to 60mm. There are jumper wires connecting these pins to the MCU dev board. (The jumper wires certainly could be causing problems)

    The microphone range from 10-30mm from the 7118

    Image of the PCB layout of one of the ADAUs; the 100nF bypass caps are towards the top.

  • Hello Alchemist,

    Thanks for the info. Thanks for confirming that you are using a four layer board with power and ground planes as the internal layers. That is great. 

    The bypass caps can be done a little bit better to allow the bypass caps to be more effective. I do not know why I did not put in a PCB layout section of the datasheet, I know we were on a tight schedule to release the part. In the ADAU1452 datasheet there is more info on PCB layout. Here is a screenshot of how you should implement the bypass caps:

    The issue you have with the 7118 is that there is only one ground pin but two power domains. 

    So what I suggest to do is to take the trace from the ground pin and split it into a "V" then on each branch connect the two bypass caps and each branch will have its own via to the ground plane. The bypass caps location is good, all you need to do is to flip each one 180 degrees so you can connect directly to the ground pin without a via in the way. The noise either from the part or from the ground plane have to pass by the bypass caps making it more effective. 

    One other detail, I would sever the connection of the ground pin to the EP ground pad under the part. Then add one or more vias to ground that only the thermal pad under the part will use. I have seen this pad be a problem for other parts when tied directly to the ground pins on the part. Now this part is really simple so I do not expect this is the issue but since I have seen it in the past it is good practice to treat the EP as its own pin with its own path to the ground plane. 

    Yes, the jumper wires could possibly be an issue were. Run ground wires with the clock signals always helps and obviously keeping them as short as possible helps. 

    See what you find with a scope. 

    Dave T

    Update:

    After I posted I wondered what I did with the eval board PCB layout and that is exactly what I did. 

    ( Glad I practice what I preach! LOL )

    Excuse the poor PDF but you see the "V" in the ground trace and the two bypass caps and then the two vias to ground above the caps. You do not see the vias to the power plane because the traces have to go to the power selection jumpers for the onboard regulators or an external power supply. 

    You can also see the grid of five vias on the thermal pad and no connection to the ground pin. 

    Thanks,

    Dave T

  • #1: Thank you very much for the layout advice regarding this. I've made the changes in CAD. (Cap layout with V trace, via in EP pad with no connection to ground pin, cap between pins and plane VIAs etc). Will take this to heart for other uses 2.

    #2:The oscilloscope shows that when (for example) 1 channel pair is enabled on a single 7118, the clock signal is clean. With a second pair enabled, it becomes slightly less defined. When a third is enabled, there's what appears to be a conflicting signal, and the MCU no longer receives data. This implies the PDM clock out is getting corrupted, somehow.

    PDM clock line, 1 pair Enabled (clean):

    2 pairs enabled (slightly blurry):

    4 pairs enabled (Corrupted; no data received):

    The oscilloscope also shows what I assume is noisy ground near the caps, but need to examine that further.

  • Hello The Alchemist,

    Yes, it does seem like noise getting onto the planes is causing this. The more you enable the more energy that will be dumped onto the planes. 

    Before focusing on the PDM clocks too much, what is going on with the PDM data lines? 

    If the data coming out of the PDM mics stops when you enable the third channel pair? If the data goes away then you are correct to look at the PDM clock. If it continues then it may be the TDM bitclock or Frame clock that is getting really bad. 

    That said, if there is a lot of noise getting into the system is can come from any clock so the noise might be from the DPM clocks but I think it is coming from the bit clock. It looks like a higher frequency than the PDM clock. I bet if you took another probe and attached it to the bit clock it would line up and be correlated to this low level noise you see. 

    So the answer is good grounding, good power, good bypassing, good transmission line design for all the clocks and data and then I think you will make this all work. All of these details help to keep noise off of the power and ground planes which help the digital threshold levels in the parts to stay stable. It is kind of like you trying to have good penmanship writing on a white board while standing on a trampoline. You can probably do it if you are by yourself on it. Then try it with others jumping on it. Your reference level keeps changing. 

    ( I should make funny videos about these concepts. ) LOL

    Dave T

  • I ordered a new board with your changes. It works! Probably completely solved. Thank you!

Reply Children
No Data