Hello, I've been trying to get some data samples from the ICM20602 IMU using the mpu6050 driver which recently added support for it, but I'm encountering an issue with the ordering of the data in the FIFO. According to the specs of the device, if the accel and gyro XYZ channels are enabled, then the hardware FIFO is filled with 14 bytes corresponding to the following channels: accel_x, accel_y, accel_z, temp, anglvel_x, anglvel_y, anglvel_z. However, when reading out the buffer, the value I get for anglvel_x seems to actually be the temperature. This occurs both when reading with iio_channel_read (via libiio) and also if I read directly from /dev/iio:device with only in_anglvel_x_en set. But in_anglvel_x_raw reports correct values, which made me suspect that maybe somewhere in the driver this interleaved temp channel is not accounted for in the buffer structure.
I had a look at the driver code and inv_mpu6050_read_fifo() in particular, but I can't identify anything amiss. I've applied the recent patch that added the extra 2 temperature bytes (https://patchwork.kernel.org/patch/10882883/), but the problem persists. So far I've tried changing the size of the data buffer, defined in inv_mpu_iio.h: /* 6 + 6 round up and plus 8 */ #define INV_MPU6050_OUTPUT_DATA_SIZE 24 from 24 to 32, according to the intuition that 24 corresponds to readings without temperature (i.e. 6 bytes for accel, rounded up to 8 + 6 bytes for gyro, rounded up to 8 + 8 bytes for the timestamp = 24) and thus another 8 bytes would be needed, but that doesn't seem to have solved it. I'm quite new to driver development though, so I think there might be something I'm not getting. I would be really grateful if anyone could shed some light over what's happening here or give some advice as to what I could be doing wrong. Best regards, Andreea Lutac
