Hi Andreea, I understand the issue now. The problem is that temperature data are always present in the FIFO. Even when the attribute is disabled. This is a limitation of this chip and cannot be changed on the hardware side.
When temp attribute is disabled while accel and gyro are on, the iio buffer is expecting to have 12 bytes with accel + gyro data. But the driver will still provides 14 bytes with temperature in the middle since the FIFO will contain that. Always enabling temperature attribute on userspace will solve this issue, but that's certainly not the best. A correct solution would be to enforce temperature data in iio buffer by having the temp attribute always enabled and read-only in userspace. That would reflect correctly the chip capabilities. But I don't know if this is feasible. A workaround would be to add data post-processing in the driver and delete temp data when it is disabled. But I don't like this kind of workaround because that goes against iio buffer design principle. Hope this help you. Best regards, Jean-Baptiste Maneyrol From: Andreea Lutac <andreea.lu...@fixposition.ch> Sent: Thursday, May 23, 2019 11:44 To: Jean-Baptiste Maneyrol Cc: stev...@skydio.com; ji...@kernel.org; knaac...@gmx.de; l...@metafoo.de; pme...@pmeerw.net; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org Subject: Re: ICM20602 buffer issues with the inv_mpu6050 driver CAUTION: This email originated from outside of the organization. Please make sure the sender is who they say they are and do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Jean-Baptiste and Stepan, Thanks so much for the replies and the advice. I've dug a bit deeper into this and added a few printk statements to the driver, as suggested by Stepan. It looks like the device is getting recognized correctly as ICM20602 and the buffer is being filled with 14 bytes as expected. But I've identified some strange behaviour regarding the temperature channeI. If I manually enable all 7 scan elements and read 14 bytes from the device file, the readings appear correct and change accordingly when I move the chip around. However, if I set in_temp_en set to 0 (with everything else still enabled) and read 12 bytes, the buffer doesn't seem to acknowledge this change and shift the gyro values up, instead getting only the first 12 bytes (accel_x, accel_y, accel_z, temp, gyro_x, gyro_y), without gyro_z. So this is why it looks as if temp is replacing gyro_x. I made a pastebin here with some of the (unconverted) values I got while testing these cases: https://urldefense.proofpoint.com/v2/url?u=https-3A__pastebin.com_BYVqDNch&d=DwIFaQ&c=WoJWtq5JV8YrKnzRxvD8NxmTP_1wxfE0prPmo0NeZwg&r=4jiDX_1brsSWfCjfA6Ovj1d4h9MF8q7Xk5aBwG28mVk&m=sbkHiUlsj8pOWjf2iTq5CXEFvv-MNyqBKOqCjxOj9kc&s=Pmb23R-DoTj9hDwYk3qqiUfOCUWbtfpVQjUZ1lajeFI&e= Attempting the same reads with my C++ program via libiio always results in only the first 12 bytes being read, as for some strange reason libiio fails to enable the temperature channel, so iio_device_get_sample_size() is always 12 and it's actually gyro_z that I can't get to. I'll try to look through the code that is supposed to enable a channel and see why it's not succeeding via libiio. Do you have any clue as to which bit of code does the adjustment of the buffer values according to which channels are enabled? Is this done in the driver or deeper in the kernel? Thanks once again for the help! Best regards, Andreea On Wednesday, May 22, 2019 16:33 CEST, Jean-Baptiste Maneyrol <jmaney...@invensense.com> wrote: > Hello, > > I had a look inside the driver to verify the buffer implementation. It looks > correct to me. I don't see where the problem can come from. I am sorry I > don't have a setup currently to test in live. > > For sure you can have a different result by reading the buffer through the > char device file compared to reading the raw sysfs entry. The buffer is > taking the data from the FIFO and the raw sysfs from the sensor data > registers. > > You can perhaps test value 1 by 1 in the buffer, and verify the correctness > of every attributes. If you can also send a complete buffer log that would be > helpful. > Every data is 2 bytes long and in the following order: accel_x, accel_y, > accel_z, temp, gyro_x, gyro_y, gyro_z > > Best regards, > JB Maneyrol > > From: Andreea Lutac <andreea.lu...@fixposition.ch> > Sent: Tuesday, May 21, 2019 12:40 > Cc: Jean-Baptiste Maneyrol; stev...@skydio.com; ji...@kernel.org; > knaac...@gmx.de; l...@metafoo.de; pme...@pmeerw.net; > linux-...@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: ICM20602 buffer issues with the inv_mpu6050 driver > > 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 ( ), 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 >
