Libiio buffered measurements are not working with the Max11617 when the device has 12 channels.

Hi roryn ,

Sorry about the late reply. When you said the only thing changed is the device package, it means you switched from an 8 channel MAX11617 to a 12 channel MAX11617? I am not aware of an 8 channel MAX11617. 8 channel devices in the family are MAX11614/MAX11615. Could you double check if that is the case?

Thanks,

Kevin

No worries,

Now that you've mentioned it, I took another look at the data sheet and realized I was confused. The (N.C) markings on the QSOP package through me off. I thought the QSOP package we had on our test bench (first setup) had a reduced number of channels and our HW team had placed a different package with all channels connected on our board (second setup). Now I realize we have the QSOP on both setups and this has all 12 channels. So then the only difference between the two is that channels 8, 9 and 10 are connected to an analog stage.

Hi,

When you said the only difference between the two setups now is that the problematic one has channel 8, 9, 10 connected to an analog stage. Are you trying to read from these three channels then?

Previously you mentioned you are not able to read from the same 8 channels with the same code. Does that mean your problematic setup is still reading from the same 8 channels as your working setup but with channel 8~10 connected?

Hi, 

Yes, sorry I have to revise what I said a little more.

Setup 1: I'm using libiio to read from channels 0 through 10 on the MAX11617. This is on a breakout board so I've been testing channels individually meaning some will  be floating some will not but I've never tested channels 8, 9, 10 on this setup so they were always floating. All of the channels I tested returned values that matched my test signal.

Setup 2: I've deployed the same image that uses libiio with a buffer to our custom hardware that is also using the MAX11617. Channels 0 through 10 are all connected to a signal and now the buffer no longer returns values that make sense. If I disable all but one channel, the enabled channel returns the correct value. If I disable the buffer and read channels individually, the values make sense. 

Hi, 

Yes, sorry I have to revise what I said a little more.

Setup 1: I'm using libiio to read from channels 0 through 10 on the MAX11617. This is on a breakout board so I've been testing channels individually meaning some will  be floating some will not but I've never tested channels 8, 9, 10 on this setup so they were always floating. All of the channels I tested returned values that matched my test signal.

Setup 2: I've deployed the same image that uses libiio with a buffer to our custom hardware that is also using the MAX11617. Channels 0 through 10 are all connected to a signal and now the buffer no longer returns values that make sense. If I disable all but one channel, the enabled channel returns the correct value. If I disable the buffer and read channels individually, the values make sense. 

Hi,

After I discussed this with my team, we think this is very likely a libiio problem. None of us are familiar with the platform, so I recommend contacting technical support first and see if they have any knowledge on libiio: Support | Analog Devices

Hi again,

So after some investigation, we think the issue is because our hardware is using an isolator with a monodirectional clock. It looks like the ADC needs to provide some clock stretching when we scan channels and it's unable to do this because of the isolator. If we could setup the device to use an external clock for the conversions, our problems possibly could be solved as it will no longer need to stretch the clock. It seems the MAX1363 driver by default configures the device to use an internal clock. Is it possible to use the driver to configure the device for using an external clock?

Thanks

Just to add to the above comment, selecting a different isolator might not be an option for use. It's difficult to find a part with a bidirectional clock that fits are creepage/clearance requirements.

Hi roryn 

Using an external clock should solve the problem. The datasheet for MAX11617 has the details on page 17. Another potential solution is to slow down the I2C bus manually to prevent clock stretching.

Thanks,

Kevin

Are we able to configure the max1363 driver to do either of what you mentioned?

Page 12 of MAX1363 datasheet should have the information you need.

roryn 

It looks like the driver hard-codes the clock to internal:

https://github.com/analogdevicesinc/linux/blob/main/drivers/iio/adc/max1363.c#L1440

The I2C frequency can be controlled through the device tree, here's an example where we're setting it to 400 KHz on a Raspberry Pi:

https://github.com/analogdevicesinc/linux/blob/rpi-5.15.y/arch/arm/boot/dts/overlays/rpi-ltc2497-overlay.dts#L34

Try reducing the clock frequency, but note that only certain frequencies may be available depending on what platform you're using (you didn't specify, what are you using?) And it's always a good idea to double-check with an oscilloscope.