We have an SSM2537 evaluation board, which is hooked up to our custom FPGA setup. The device seems to work fine when we stream audio PDM at either 3 or 6MHz. But when we send a control pattern (as defined in the datasheet table 8), there is no reaction. We have tried to modify the PDM signal in all possible ways imaginable (e.g. sending patterns on both left and right channels, or alternating), tried sending either 130 repeats or 40000 repeats. Nothing happens. Looking at the oscilloscope, the sent pattern looks fine. VHDL simulation says the pattern repeats fine.
Is there anything we can do about this. Is there something in the patterns to consider, that is not obvious from the datasheet? Is there errata for or newer versions than "revision 0" of the SSM2357 datasheet?
And finally - when sending the 'mute' pattern 0x66, should the device stay muted even when the PDM data switches back from mute to data - untill a clock-loss powerdown is done, or is the mute effective only during when the pattern is sent?
thank you in advance,
There must be something simple that is causing the issue. The signal needs to be on the selected channel based on the LRSEL pin. 130 repeats are all that should be required for the control patterns that set a setting. For the Mute and Power-down patterns, they must be sent continuously for the setting to be "held". As soon as the message stops the part will come out of mute or power up depending on the command. So to mute the part you must continuously transmit the 0x66 pattern.
So how are you sending the pattern? You should stop sending audio data and start sending the pattern MSB first with no extra bits inserted.
You must continue to send the PDM clock.
I assume you are hearing audio out of the part so the transmission levels are correct? I am trying to think of what we could be missing here.
So if you could answer these few questions and then I will research this further.
Thanks for your reply. I appreciate it being difficult to debug this kind of error remotely, over a forum like this
We found the issue, and the chip started working.
The long story: I received the 2537 eval board user guide from our local FAE. This guide suggested the timings of the 2537 eval board are identical to the 2517 eval board. I never found the 2537 user guide on Analog's web pages, only an older question here where AndyR says the evalboard userguides are identical, but I guess I thought the timings was to be taken from the chip datasheet and applied.
According to the chip datasheets, the 2537 and 2517 chips have slightly different timing requirements, and we naturally adjusted the clock to match the one in the 2537 datasheet. By unhappy accident, the data assertion time was exactly on the edge of Tds minimum value (2517 datasheet, table 3). So, taking a long shot, we adjusted the data timing to match the 2517 datasheet and 2537 userguide, and the chip started recognizing the control pattern So this seems to be an error in the 2537 chip datasheet?
Now in hindsight, I remember there being random occurrences of the audio stream turning into noise, but I thought I fixed that when dropping the supply voltage from 3.6 to 2.5V. I guess it did something towards that, but only partially. Ohwell, a learning experience
thanks to all involved,
I see your point about the timing diagram in the 2517 datasheet. It could be drawn better since it shows the data not even being valid during the clock edge and that is where it needs to be valid! Table 3 of the 2537 datasheet is much better but it does not show the rise and fall time. I would have to research this, and that would be very time consuming, but I am pretty sure that the Tds setup time should be measured from when the clock is just starting its transition. The Tdh time should be from the end of the transition. This will make the rise and fall time to be added to the setup and hold times. So using worst cases you would have 10ns of setup time then 10ns of rise or fall time then the 7ns of hold time. This should give you plenty of margin to account for process variations and temperature variations.
Regarding your statement about the random noise that improved when you lowered the supply voltage. This tells me that there are some signal integrity issues where the drive strength might be too high or needs to be damped and by lowering the voltage it would improve. I would be glad to have a look at your design and layout if you like. Just contact me directly about it.
that is how I interpret the 2537 datasheet too.
We had a clean data transition approximately 40ns before the clock edge (either edge) (i.e. tds) and the data kept stable over the clock edge - this wouldn't work. Shifting the transition to ~50 ns before clock edge (and keeping the data stable >7ns after the clock edge, i.e. tdh) helped.
2517 datasheet specifies tds=44ns minimum.
About the noise: the PDM signal driver is a Xilinx Zynq FPGA, driving it at 1.8V and with the default driver. This is connected directly to the evalboard PDM inputs. The eval board is fed 2.5V PVdd, and generates the IO Vdd onboard.
With the new timings the random noise doesn't seem to appear again. Ofcourse it occurred a bit randomly previously aswell.
Edit: meant to say I tried PVdd 2.5, 3.6 and 5V - I couldn't get the random noise to repeat.
How are you connecting between the FPGA board and the eval board? I assume you are using "fly wires" to connect the two? I deal with this often in the lab. I have to keep the lines short and make sure the two boards are grounded together. However, you may find that twisting a ground wire around the signal lines connected to both boards may help. You are probably getting reflections and with no ground wire close to the signal wire you will have an undefined impedance along the 10 or 12 inches of fly-wire. So this is probably what is causing the issue with the PDM pattern not working at the 40ns setting. If you are getting some random errors and bits dropping in the audio it can be difficult to hear but if it happens during the pattern transmission then one bit wrong during the 128 bytes transferred and the counter starts over. So 1024 bits must be transferred with no errors.
So I predict that these issues will all go away once you place this all on your own PCB. For now you can try to run the signals on a ribbon with ground on either side of the signal lines. The impedance will not be perfect but it is better than it being undefined.
Like I said earlier, I deal with this in the lab often. When using I2S at 192kHz it can be quite delicate! I can slightly move the wires and the loud noise is heard or clicks. Touching the wires can make it come and go and I shift them around until I can get them to work well enough to perform tests. Just a few twists of a ground wire will help usually and keeping the wires low near the ground plane also helps.
I am glad you are up and running at this point.