mpu9250 iio buffer not working

[DanG]

Direct reading works fine
# cat in_*_raw
3492
428
15876
2
8
17
5257
# cat in_*_raw
3544
628
16144
1
8
19
5267
#
# for en in scan_elements/*_en do; echo 1 > $en; done
# echo 100 > buffer/length
# echo 1 > buffer/enable
# cat /dev/iio:device0 | xxd –
^C
#
# cat buffer/data_available
0
#

I expect to get a stream of data but get nothing…

What am I doing wrong, or missing?

[Eshtaartha Basu]

Hello DanG,

Please provide a little more information so that we can help you further:

1. We assume you’re using the OSD3358-SM-RED board. Is that right?

2. Are you using the RED Debian image from our website or one of the Beagleboard images?

3. Which version of the Debian image are you using (E.g., 8.7 or 9.1 or 9.3 etc)?

4. Please provide the outputs of “uname -a” and “cat /etc/debian_version” commands.

5. It looks like your previous attachments (kernel.config and .dts file) did not get uploaded successfully due to security reasons. Please add the files to a ZIP archive and re-upload them.

[DanG]

I’m using buildroot-2019.05 with OSD3358-SM-RED. See attachment for configuration details (created with tar cj).

[DanG]

This one is just plain zip, as requested. Hope it works.

• This reply was modified 5 years, 4 months ago by DanG.
• This reply was modified 5 years, 4 months ago by DanG.
• This reply was modified 5 years, 4 months ago by DanG.

Attachments:

1. mpu9250-iio-buffer-not-working-post-8450.zip

[Eshtaartha Basu]

Hello DanG,

Thanks for pointing this out.

The pin mux of the hardware interrupt pin (GPIO3_2) was not fully initialized in the RED device tree. Since the MPU9x50 driver was not able to read any interrupt signals from the sensor module, the data was not being read into the buffer. We have fixed our device tree files to bind GPIO3_2 interrupt pin with appropriate GPIO controller (You can now see a new phandle “&ocp” under osd3358-bsm-refdesign.dts).

If you wish to use our RED image (Debian 9.1) or any custom image before Debian 9.5, use https://github.com/octavosystems/OSD335x-Device-Tree/tree/v4.9-2 device tree files

If you wish to use Debian 9.5 or later image, use https://github.com/octavosystems/OSD335x-Device-Tree/tree/4.14-2

We were able to verify the sensor data on the RED board:

# cd /sys/bus/iio/devices/iio:device1
# for en in scan_elements/*_en; do echo 1 > “$en”;done
# echo 100 > buffer/length
# echo 1 > buffer/enable
# hexdump /dev/iio\:device1

[DanG]

Hi Eshtaartha,
Thank you for the diagnosis and remedy. I’ve verified using the v4.9-2 dtb.

Unfortunately, for me, the 4.19.37 rt configuration deadlocks as soon as I enable the buffer (echo 1 > buffer/enable). Prior to your imu_int_en addition, the deadlock I could cause a deadlock by enabling the buffer and then cat in_accel_x_raw. I happened to do that by accident. Of course, this issue isn’t an Octavo Systems problem; I’m using a different kernel and file system and the mpu driver isn’t even yours.

In case you are interested to help, the updated dts[i], .patch, and log are attached.

Thanks, again, for your valuable help!

Attachments:

1. mpu9150-iio-buf-deadlock.zip

[DanG]

Looks like the mpu6050 driver has not been tested with PREEMPT_RT_FULL. I’ll post back when I find a solution to that problem.

Thank you

[DanG]

I must retract my statement regarding mpu6050 driver and PREEMPT_RT, from above. It works!

I suspect I had failed to make linux-rebuild to compile the corrected .dts file.

[Author]

Posts