STMPE811 IIO timeouts on read and confuses values

Technical Support
, , , ,
1

Image: 2.8b5

I’m using C to access the ADC using sysfs.

(/sys/bus/iio/devices/iio:device0/in_voltage4_raw AND in_voltage5_raw)

I first read channel 4, immediately afterwards I read channel 5.
Then I wait for 50ms and repeat.

Sometimes the wrong values (of the other channel) are read,
sometimes they timeout during a read.
Trying to use cat on one of these channels results in

cat /sys/bus/iio/devices/iio\:device0/in_voltage4_raw 
cat: read error: Connection timed out
(same for in_voltage5_raw)

This stays that way until another unrelated channel is read.
This problem does not occur when only one channel is read.

2

A quick example program and the log demonstrating the problem .

3

I assume you already looked at our developer website article:

Have you tried direct programmatically reading the ADCs e.g. as in the Continuous Sampling example? Alternatively, you may also try using a library such as libiio:

https://layers.openembedded.org/layerindex/recipe/57509/

4

I don’t have any hard timing requirements.
So it’s not necessary to buffer the values (which is why I would like to keep CONFIG_IIO_SYSFS_TRIGGER and related kernel options off).
Furthermore, libiio seems to come with much more than needed and ends up using the same instructions in overall.
I’m not sure, if this has something to do with I2C in general, with the driver or with the way I’m reading the values.
Either way, I’m currently working around this using a small sleep between the two reads which seems to work just fine.

5

Using libiio, the same issue occurs.

6

Ok, thanks. I guess we will have to look at it more closely. By any chance you tried mainline which should have such ADC support now as well?

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/imx6qdl-colibri.dtsi?h=v5.1-rc3#n291

7

I will try mainline now.

8

With mainline kernel (5.1.0-rc3 commit 145f47c73) the issue is still present.
It does not occur the first time I start looping with my test program,
but after I restart it, it starts mixing up the values.
I tested this with the Iris Carrier board and with our board as well.
example program

Restarting once more results in the timeouts as mentioned before.
When reading an unrelated channel it works again, as if freshly rebooted.

Example output

root@colibri-imx6:~# ./a.out 
^C
root@colibri-imx6:~# ./a.out 
Channel 4:2287
Channel 4:2287
^C
root@colibri-imx6:~# ./a.out 
Channel 5:0
Channel 5:0
^C
root@colibri-imx6:~# cat /sys/bus/iio/devices/iio\:device0/in_voltage6_raw 
1023
root@colibri-imx6:~# ./a.out 
^C
root@colibri-imx6:~# ./a.out 
Channel 5:862
Channel 5:862
Channel 5:862
^C
root@colibri-imx6:~# ./a.out 
Channel 5:0
Channel 5:0
^C
root@colibri-imx6:~# ./a.out 
Channel 5:0
Channel 5:0

For reference, on channel 4 are 0.69V (862 raw) on channel 5 1.86V (2285 raw).
When Channel 5 timeouts it outputs 0 (due to atoi not finding anything)

9

Hi @PatZ

I tried to reproduce your issue here and was sometimes successful. I also have an idea about what could go wrong in our stmpe-adc driver. It could be that this is interrupt-related.

In order to solve the issue I need to be able to reproduce this issue more stable, so I can tell afterwards if the patch is successful or not. Could you tell me more about your test setup and what is running in background? Have you connected a resistive touch display?

I saw your described error only the first time your program is executed. How much do you see this error?

10

Hi @philippe.tx

The resistive touch display is connected on the Iris board.

However on our own board, the resistive touch is not connected (however it hasn’t yet been removed from DT), but the result seems unaffected.

For latter one we use a simple GTK app which uses the same functions as in the last program I’ve provided. An error is visible there approximately every 5 seconds.

11

Using the “-pg” compile flag for profiling, made the error occur more consistently in our case.

13

Hi @jaski.tx,

the issue currently has very low priority.
With the profiler flag disabled, it also barely occurs.
For our application it doesn’t need to be fixed any time soon.

15

Thanks for your Input. We will try to fix this issue soon. You can check this site to know when the issue is solved.

16

Hi @PatZ

We introduced a fix for this Issue now. You can get it from here.

Best regards,
Jaski