MPU9250 FIFO Data corruption

[lasithf]

Hi Kris,

I am seeing a strange behaviour from the MPU9250 FIFO. At some point I am getting FIFO data corrupted! When I look at the data registers for accelerometer (accel), if I print them along with the FIFO data, I can see the accel data registers are quite accurate while at the same time FIFO got some unrealistic large values in the accel data xyz.

Power cycle the MPU9250 seems fixing this issue, but I don’t know what is the root cause.

It looks like when accessing the data registers directly while the FIFO is enabled and running causing FIFO data alignment issue (just a thought!). As I have enabled only accelerometer and magnetometer go in to the FIFO, which is 13 bytes in total, I suspect when I access data registers could cause FIFO data to corrupt (mis-aligned).

Any thoughts what would be going on here? Appreciate your help.

[kriswiner]

How do you configure the fifo to accept magnetometer data?

On Mon, Sep 9, 2019 at 4:09 PM lasithf notifications@github.com wrote:

Hi Kris,

I am seeing a strange behaviour from the MPU9250 FIFO. At some point I am getting FIFO data corrupted! When I look at the data registers for accelerometer (accel), if I print them along with the FIFO data, I can see the accel data registers are quite accurate while at the same time FIFO got some unrealistic large values in the accel data xyz.

Power cycle the MPU9250 seems fixing this issue, but I don’t know what is the root cause.

It looks like when accessing the data registers directly while the FIFO is enabled and running causing FIFO data alignment issue (just a thought!). As I have enabled only accelerometer and magnetometer go in to the FIFO, which is 13 bytes in total, I suspect when I access data registers could cause FIFO data to corrupt (mis-aligned).

Any thoughts what would be going on here? Appreciate your help.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/384?email_source=notifications&email_token=ABTDLKQEWT36UQFIVUBZSLLQI3JSHA5CNFSM4IVBB2M2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HKJWEDQ, or mute the thread https://github.com/notifications/unsubscribe-auth/ABTDLKXBI4OLYBJEUBBHYI3QI3JSHANCNFSM4IVBB2MQ .

[lasithf]

Yes, I did. my configuration does enable both accel and mag data to FIFO.

Further when I see this issue, I was able to print accel/mag data registers, offset registers and FIFO readings. I can see data registers and offset registers are quite consistant and valid where as FIFO is corrupted.

[kriswiner]

I asked HOW you configured the FIFO to accept magnetometer data.

On Mon, Sep 9, 2019 at 4:21 PM lasithf notifications@github.com wrote:

Yes, I did. my configuration is to enable both accel and mag data to FIFO.

Further when I see this issue, I was able to print accel/mag data registers, offset registers and FIFO readings. I can see data registers and offset registers are quite consistant and valid where as FIFO is corrupted.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/384?email_source=notifications&email_token=ABTDLKXAT4N4J4HE7S3RLD3QI3K7DA5CNFSM4IVBB2M2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6JKI5Q#issuecomment-529704054, or mute the thread https://github.com/notifications/unsubscribe-auth/ABTDLKQ4AYNZK2CQIHZ3PYDQI3K7DANCNFSM4IVBB2MQ .

[lasithf]

Appologies, First I set the magnetometer to continuous measurement mode with data size to 7 (3 axes x 2-bytes + 1 byte read end).

Then I set the Reg 0x22 to 0x89 (enabling temp, accel & mag - slave_0 is the magnetometer).

After that Reg 0x6A to 0x64 (to enable I2C master, enable FIFO and reset).

I also set the accel config 0x1C to have 2g.

[kriswiner]

Perhaps the trouble arises from how you reconstruct the bytes from the FIFO? Is it the case that the FIFO results are correct for a while and then become corrupted? Perhaps then you are running out of FIFO or do not clear the FIFO properly?

On Mon, Sep 9, 2019 at 4:40 PM lasithf notifications@github.com wrote:

Appologies, First I set the magnetometer to continuous measurement mode with data size to 7 (3 axes x 2-bytes + 1 byte read end).

Then I set the Reg 0x22 to 0x89 (enabling temp, accel & mag - slave_0 is the magnetometer).

After that Reg 0x6A to 0x64 (to enable I2C master, enable FIFO and reset).

I also set the accel config 0x1C to have 2g.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/384?email_source=notifications&email_token=ABTDLKTYIIOCDI4FSN5N53LQI3NFZA5CNFSM4IVBB2M2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6JLHQI#issuecomment-529707969, or mute the thread https://github.com/notifications/unsubscribe-auth/ABTDLKX7XTXGIOYP7XS5CODQI3NFZANCNFSM4IVBB2MQ .

[lasithf]

I am reading FIFO records to a structure.

The corruption comes after running correctly for some time, I am not waiting until FIFO overflow interrupt happens, the 9250 thread is running fast enough to access FIFO data before it overflows, however there may be a scenario that due to some task delay it may delay accessing the FIFO data and leading to a FIFO overrun.

I want to understand if this is the case, how does resetting FIFO (Reg 0x6A write 0x04) fix the issue? Does resetting FIFO take care of the proper alignment of FIFO data? Since reset FIFO is a asynchronous call, it may happen while accel data is being written to the FIFO (just an example) and when reset does it start again with the accel data or simply continue with mag data from the start of the FIFO?

Or else should I disable the FIFO first and then re-enable it with FIFO reset?

[kriswiner]

Could be that your I2C API is too slow to read all of the FIFO data when requested.

Did you try to drop the accel sample rate to 100 Hz?

Maybe increase the I2C bus speed to 400 kHz or 1 MHz?

On Mon, Sep 9, 2019 at 5:03 PM lasithf notifications@github.com wrote:

I am reading FIFO records to a structure.

The corruption comes after running correctly for some time, I am not waiting until FIFO overflow interrupt happens, the 9250 thread is running fast enough to access FIFO data before it overflows, however there may be a scenario that due to some task delay it may delay accessing the FIFO data and leading to a FIFO overrun.

I want to understand if this is the case, how does resetting FIFO (Reg 0x6A write 0x04) fix the issue? Does resetting FIFO take care of the proper alignment of FIFO data? Since reset FIFO is a asynchronous call, it may happen while accel data is being written to the FIFO (just an example) and when reset does it start again with the accel data or simply continue with mag data from the start of the FIFO?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/384?email_source=notifications&email_token=ABTDLKTBJB7DY4Q7NS4D3W3QI3P4RA5CNFSM4IVBB2M2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6JMM2Y#issuecomment-529712747, or mute the thread https://github.com/notifications/unsubscribe-auth/ABTDLKTFJIYJKEFQGBGVY5TQI3P4RANCNFSM4IVBB2MQ .

[lasithf]

I am using SPI to read FIFO data and the sample rate is 62.5Hz,

I am seeing both accelerometer & magnetometer data getting corrupted in this situation.

Would this be a problem with the FIFO reset? What's the better approach to reset the FIFO? Do we need to disable FIFO first and then re-enable with a reset?

Let's say that we have a FIFO overflow occurrence, and I wonder how the overflow handles gracefully in the 9250?

[kriswiner]

If you are not reading the FIFO fast enough you could be overwriting or otherwise corrupting the data.

What is the bus speed you are using?

Did you try low sensor sample rates and higher bus speeds?

On Mon, Sep 9, 2019 at 5:36 PM lasithf notifications@github.com wrote:

You talking about magnetometer data? I am seeing both accelerometer & magnetometer data getting corrupted in this situation. So I am trying to understand how I2C bus speed (for mag sensor) effecting this?

Would this be a problem with the FIFO reset? What's the better approach to reset the FIFO? Do we need to disable FIFO first and then re-enable with a reset?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/384?email_source=notifications&email_token=ABTDLKQKXI6RFS3AEAVQAR3QI3TXRA5CNFSM4IVBB2M2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6JN5BQ#issuecomment-529718918, or mute the thread https://github.com/notifications/unsubscribe-auth/ABTDLKSVHA6YOACTN5ONJELQI3TXRANCNFSM4IVBB2MQ .

[lasithf]

I understand.

If there's a corruption, can we reset/reconfigure to overcome this issue?

[kriswiner]

Maybe but this doesn't solve the root problem.

Again, what is the I2C bus speed you are using?

Have you tried a higher I2C bus speed?

What is the accel sample rate you are using?

Have you tried a lower accel sample rate?

The answers could tell if it is your I2C API that is the problem. What is your MCU?

On Mon, Sep 9, 2019 at 5:41 PM lasithf notifications@github.com wrote:

I understand.

If there's a corruption, can we reset/reconfigure to overcome this issue?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/384?email_source=notifications&email_token=ABTDLKQRXY6UE4CLVQGPUT3QI3ULVA5CNFSM4IVBB2M2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6JOEMY#issuecomment-529719859, or mute the thread https://github.com/notifications/unsubscribe-auth/ABTDLKTVNJVFRUPLUCIHH7TQI3ULVANCNFSM4IVBB2MQ .

[lasithf]

Thanks Kris, the problem is in normal circumstance (90% of time) we are getting the data to the speed that we need and we cannot reduce the sample rate or run at a much faster rate to the one we have now. However we could accept some data loss if we encounter this FIFO corruption.

Now the question is when we see there's a FIFO corruption, how do we fix it?

Do you have any idea what would be the better approach to reset/reconfigure FIFO? So that it will work until fail again and in which point we could reset/reconfigure again?

My MCU is STM32L1

[kriswiner]

I suspect your problem is slow I2C transactions.

In other words, the problem is your MCU and system layer/Arduino core not the MPU9250.

Maybe try a different/better MCU and I2C API like this https://www.tindie.com/products/tleracorp/ladybug-stm32l432-development-board/ one?

On Mon, Sep 9, 2019 at 5:56 PM lasithf notifications@github.com wrote:

Thanks Kris, the problem is in normal circumstance (90% of time) we are getting the data to the speed that we need and we cannot reduce the sample rate or run at a much faster rate to the one we have now. However we could accept some data loss if we encounter this FIFO corruption.

Now the question is when we see there's a FIFO corruption, how do we fix it?

Do you have any idea what would be the better approach to reset/reconfigure FIFO? So that it will work until fail again and in which point we could reset/reconfigure again?

My MCU is STM32L1

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/384?email_source=notifications&email_token=ABTDLKUB7M3AFVOTBERBL43QI3WCRA5CNFSM4IVBB2M2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6JOZCY#issuecomment-529722507, or mute the thread https://github.com/notifications/unsubscribe-auth/ABTDLKSXZO4NBWZKUSY2JSTQI3WCRANCNFSM4IVBB2MQ .

[lasithf]

I am not using I2C between MCU and 9250, its SPI.

And I am reading the FIFO count register before read FIFO values and it's calculation is always less than the FIFO size which is 512 bytes. This means in normal scenario SPI speed and FIFO sample rate etc works perfectly.

However I accept there is a possibility that due to taks delay I may not be able to read FIFO before it overflows. This is the point I suspect the corruption issue occurs.

When My program go and check the FIFO at this point, it also gives me <= 512 data to read, which my program reading as usual. However this data is corrupted.

That's why I think it's a 9250 FIFO overflow issue (or an issue of not resetting the FIFO properly !) rather than SPI speed issue.

As I asked, do you have any idea how to reset the FIFO properly if it ever overflows?

[kriswiner]

Run the FIFO as a circular buffer then there is no overflow, see Register 26, bit 6:

When set to ‘1’, when the fifo is full, additional writes will not be written to fifo. When set to ‘0’, when the fifo is full, additional writes will be written to the fifo, replacing the oldest data.

On Mon, Sep 9, 2019 at 6:08 PM lasithf notifications@github.com wrote:

I am not using I2C between MCU and 9250, its SPI.

And I am reading the FIFO count register before read FIFO values and it's calculation is always less than the FIFO size which is 512 bytes. This means in normal scenario SPI speed and FIFO sample rate etc works perfectly.

However I accept there is a possibility that due to taks delay I may not be able to read FIFO before it overflows. This is the point I suspect the corruption issue occurs.

When My program go and check the FIFO at this point, it also gives me <= 512 data to read, which my program reading as usual. However this data is corrupted.

That's why I think it's a 9250 FIFO overflow issue (or an issue of not resetting the FIFO properly !) rather than SPI speed issue.

As I asked, do you have any idea how to reset the FIFO properly if it ever overflows?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/384?email_source=notifications&email_token=ABTDLKTAK5G4RS5LWWC5TWLQI3XQ7A5CNFSM4IVBB2M2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6JPPII#issuecomment-529725345, or mute the thread https://github.com/notifications/unsubscribe-auth/ABTDLKSFLVYPPANHRCOKJQDQI3XQ7ANCNFSM4IVBB2MQ .

[lasithf]

Great, thanks. I will check this out.

[lasithf]

I think the issue has been fixed, mine was set to use circular buffer and overriding at overflow. I've chage that to use a linear mode and not to override at overflow, when this happens I disable and then enable the FIFO with a FIFO reset. This help to make sure we have no mis-aligned data in the FIFO. Seems working okay now, thanks for your help.

[PJiaHeng]

Hi, kriswiner.

This repository help me a lot. Thanks for your work on this repository.

Also thanks to lashitf, your issue gives me some idea.

And I suffer one problem about FIFO data accurate right now as follow:

I am using SPI Bus between MCU and 9250. And I set the Register 0x1A(CONFIG) bit 6 to 1.

• First method
  1. When FIFO overflow is happened, I read the FIFO_COUNT registers and disable data saving to FIFO buffer by setting Register 0x6A(USER_CTRL) bit 6 to 0.
  2. Then I read data from FIFO buffer.
  3. After I get all data of FIFO, I set Register 0x23(FIFO_EN) bit[6-3], bit[0] to 1 and Register 0x6A(USER_CTRL) bit 6 to 1 again.

I think the issue has been fixed, mine was set to use circular buffer and overriding at overflow. I've chage that to use a linear mode and not to override at overflow, when this happens I disable and then enable the FIFO with a FIFO reset. This help to make sure we have no mis-aligned data in the FIFO.

I can get the right data by using above way. The real sample rate is too slow (46Hz, the sample rate configuration of accl, gyro and magnet both are 100Hz).

• Second method I want to get sample rate close to sample configuration, so I only set the Register 0x1A(CONFIG) bit 6 to 1 without above operation 1 to 3. The real sample rate (96Hz) using this method is closed to sample configuration, But the data getting from FIFO by using this method isn't accurate, accel sensor data specially. In addition, I'm sure that the 9250 has been placed on a flat surface and no any motion.

So my question are:

1. Why the data is turned to inaccurate when I using second method?
2. For my second method, how to operate to make sure data accurate?

• Appendix

some data getting with the first method is as follow:

ax	ay	az	gx	gy	gz	mx	my	mz
-0.087158	-0.087891	1.005127	0.030518	0.061035	0.061035	122.949944	509.792450	98.959709
-0.086670	-0.084717	1.007813	0.030518	0.030518	0.091553	118.451775	499.296722	94.461540
-0.088135	-0.084473	1.007568	0.061035	0.000000	0.061035	115.452995	523.286926	94.461540
-0.086670	-0.088135	1.008545	0.152588	-0.030518	0.030518	121.450554	502.295502	100.459099
-0.085449	-0.083984	1.008545	0.000000	0.091553	0.000000	119.951164	512.791199	113.953606

some data getting with the second method is as follow:

ax	ay	az	gx	gy	gz	mx	my	mz
-0.0017	-0.0020	0.9363	0.0000	-0.0916	-0.0305	-103.4579	514.2906	37.4847
-0.0027	-0.0022	0.9370	0.0305	-0.0305	-0.0610	-97.4603	517.2894	28.4884
0.0010	-0.0005	0.9355	0.0610	0.0000	-0.0305	-88.4640	508.2931	40.4835
-0.0007	0.0000	0.9268	0.1221	0.0610	0.0305	-100.4591	508.2931	25.4896
-0.0010	-0.0037	0.9385	0.0916	-0.0305	0.0000	-106.4567	523.2869	37.4847

In addition, I think my magnet data is not right. If both you could spend some time giving me some advice, I will appreciate you very much. I use the calibration method from your wiki.

[kriswiner]

The actual sample rate depends on the low pass filter setting also. Compare your mag data with what is expected for your location.

On Mon, Jun 15, 2020 at 11:35 PM PJiaHeng notifications@github.com wrote:

Hi, kriswiner.

This repository help me a lot. Thanks for your work on this repository.

Also thanks to lashitf, your issue gives me some idea.

And I suffer one problem about FIFO data accurate right now as follow:

I am using SPI Bus between MCU and 9250. And I set the Register 0x1A( CONFIG) bit 6 to 1.

• First method

  1. When FIFO overflow is happened, I read the FIFO_COUNT registers and disable data saving to FIFO buffer by setting Register 0x6A(USER_CTRL) bit 6 to 0.
  2. Then I read data from FIFO buffer.
  3. After I get all data of FIFO, I set Register 0x23(FIFO_EN) bit[6-3], bit[0] to 1 and Register 0x6A(USER_CTRL) bit 6 to 1 again.

I think the issue has been fixed, mine was set to use circular buffer and overriding at overflow. I've chage that to use a linear mode and not to override at overflow, when this happens I disable and then enable the FIFO with a FIFO reset. This help to make sure we have no mis-aligned data in the FIFO.

I can get the right data by using above way. The real sample rate is too slow (46Hz, the sample rate configuration of accl, gyro and magnet both are 100Hz).

• Second method I want to get sample rate close to sample configuration, so I only set the Register 0x1A(CONFIG) bit 6 to 1 without above operation 1 to 3. The real sample rate (96Hz) using this method is closed to sample configuration, But the data getting from FIFO by using this method isn't accurate, accel sensor data specially. In addition, I'm sure that the 9250 has been placed on a flat surface and no any motion.

So my question are:

1. Why the data is turned to inaccurate when I using second method?

2. For my second method, how to operate to make sure data accurate?

   • Appendix

some data getting with the first method is as follow: ax ay az gx gy gz mx my mz -0.087158 -0.087891 1.005127 0.030518 0.061035 0.061035 122.949944 509.792450 98.959709 -0.086670 -0.084717 1.007813 0.030518 0.030518 0.091553 118.451775 499.296722 94.461540 -0.088135 -0.084473 1.007568 0.061035 0.000000 0.061035 115.452995 523.286926 94.461540 -0.086670 -0.088135 1.008545 0.152588 -0.030518 0.030518 121.450554 502.295502 100.459099 -0.085449 -0.083984 1.008545 0.000000 0.091553 0.000000 119.951164 512.791199 113.953606

some data getting with the second method is as follow: ax ay az gx gy gz mx my mz -0.0017 -0.0020 0.9363 0.0000 -0.0916 -0.0305 -103.4579 514.2906 37.4847 -0.0027 -0.0022 0.9370 0.0305 -0.0305 -0.0610 -97.4603 517.2894 28.4884 0.0010 -0.0005 0.9355 0.0610 0.0000 -0.0305 -88.4640 508.2931 40.4835 -0.0007 0.0000 0.9268 0.1221 0.0610 0.0305 -100.4591 508.2931 25.4896 -0.0010 -0.0037 0.9385 0.0916 -0.0305 0.0000 -106.4567 523.2869 37.4847

In addition, I think my magnet data is not right. If both you could spend some time giving me some advice, I will appreciate you very much. I use the calibration method from your wiki https://github.com/kriswiner/MPU6050/wiki/Simple-and-Effective-Magnetometer-Calibration .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/384#issuecomment-644562105, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKQUW7ZNNJG67BECWILRW4HD5ANCNFSM4IVBB2MQ .

[PJiaHeng]

Thank you very much.

The problem about accel data accurate has been solved. The reason is that I forget to config FCHOICE_b[1:0] to 0x00 in register 27 (Gyroscope Configuration) when 9250 inits.

After I correct this mistake, I has taken some test. And the result is satisfactory.

About magnet data, I will verify. Thanks.

[PJiaHeng]

Hi, kriswiner. Actually, the interrupt pin changes to high when FIFO happens overflow.( INT Pin Configuration register to 0x10, Interrupt Enable register to 0x10 ) But I suffer a confusion: Sometimes, the int pin change to high although the FIFO count is 0 and INT Status register is 0. The datas read from FIFO are error in this situation.

[kriswiner]

So you have the INT cleared on any read and an interrupt set for FIFO overflow.

What is the size of the FIFO data you are using? The oldest FIFO data is lost when overflow happens. If you are only storing one set of data, then you could be losing it upon overflow.

Otherwise, I have no idea why this might happen.

On Tue, Jul 21, 2020 at 8:37 PM PJiaHeng notifications@github.com wrote:

Hi, kriswiner. Actually, the interrupt pin changes to high when FIFO happens overflow.( INT Pin Configuration register to 0x10, Interrupt Enable register to 0x10 ) But I suffer a confusion: Sometimes, the int pin change to high although the FIFO count is 0 and INT Status register is 0. The datas read from FIFO are error in this situation.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/384#issuecomment-662222725, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKUNNTRD6C6K2BICHRDR4ZNIBANCNFSM4IVBB2MQ .

[PJiaHeng]

The bit FIFO MODE of Cofiguration register is set to '1' (When set to ‘1’, when the fifo is full, additional writes will not be written to fifo). The sample rate is 100Hz. The accel DLPF configuration is 44.8Hz bandwidth, gyro DLPF configuration is 41Hz bandwitdth.

[kriswiner]

No idea.

Max FIFO bytes is 512, so 512/12 = ~42 sets of data. So at 100 Hz sample rate, you should be getting a FIFO full interrupt every 420 ms or so. Is this the case?

On Tue, Jul 21, 2020 at 8:53 PM PJiaHeng notifications@github.com wrote:

The bit FIFO MODE of Cofiguration register is set to '1' (When set to ‘1’, when the fifo is full, additional writes will not be written to fifo). The sample rate is 100Hz. The accel DLPF configuration is 44.8Hz bandwidth, gyro DLPF configuration is 41Hz bandwitdth.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/384#issuecomment-662226233, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKQHX4YPQCYNTEQ6OFTR4ZPDLANCNFSM4IVBB2MQ .

[PJiaHeng]

The FIFO data size I used is 19 bytes. When FIFO is overflow, I can get 26 sets data. But there is 18 bytes data is no uesd because it is no incomplete. I think no data is over flow because I set FIFO MODE to 1.

[kriswiner]

So you are including the mag data and temperature data for the 19 bytes?

So it is only the last data set that is giving you trouble?

On Tue, Jul 21, 2020 at 9:00 PM PJiaHeng notifications@github.com wrote:

The FIFO data size I used is 19 bytes. When FIFO is overflow, I can get 26 sets data. But there is 18 bytes data is no uesd because it is no incomplete. I think no data is over flow because I set FIFO MODE to 1.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/384#issuecomment-662227775, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKQVIDHJ5GMBT3PRBTDR4ZP4VANCNFSM4IVBB2MQ .

[PJiaHeng]

I get every FIFO full interrupt just spend ~120ms

[PJiaHeng]

accel gyro and mag ( include one byte is ST1 )

[kriswiner]

At 100 Hz you should be getting one interrupt every~250 ms...

On Tue, Jul 21, 2020 at 9:06 PM PJiaHeng notifications@github.com wrote:

accel gyro and mag ( include one byte is ST1 )

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/384#issuecomment-662229271, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKSDUB62PIKRRMAUUF3R4ZQVLANCNFSM4IVBB2MQ .

[PJiaHeng]

The all datas I get from FIFO are error once int pin change to high when the fifo count is 0 and int status is 0

[PJiaHeng]

I get the FIFO data using SPI with STM32 DMA. The DMA is set to get 512 bytes once transmission. I have no idea where may I have mIstakes. FIFO configuration or DMA.

I have another question: After I just get 494 bytes from FIFO buffer, can new data be write in FIFO buffer? And will the 18 bytes data I no read be overflow?

[kriswiner]

As far as I know, you can write up to 512 bytes to the FIFO. So yes.

Maybe you should allow FIFO overwrite so oldest data is discarded and only latest 494 bytes are available on interrupt?

On Tue, Jul 21, 2020 at 9:21 PM PJiaHeng notifications@github.com wrote:

I get the FIFO data using SPI with STM32 DMA. The DMA is set to get 512 bytes once transmission. I have no idea where may I have mIstakes. FIFO configuration or DMA.

I have another question: After I just get 494 bytes from FIFO buffer, can new data be write in FIFO buffer? And will the 18 bytes data I no read be overflow?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/384#issuecomment-662232610, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKQUNCMJFNKHI32UTH3R4ZSOJANCNFSM4IVBB2MQ .

[PJiaHeng]

I have done as you suggest: change FIFO MODE and read the last 494 bytes to DMA.

It goes right that the FIFO count is 512 and int status is 0x71 when the int pin changes to high. But the situation is not as expected. FIFO datas till go error as previous sometimes, include the time token between two times to read FIFO buffer.

When I get FIFO data without DMA (STM32), it is no error data. So I consider maybe I take some mistakes about getting FIFO data to DMA.

[CatInTheRain]

I get the FIFO data using SPI with STM32 DMA. The DMA is set to get 512 bytes once transmission. I have no idea where may I have mIstakes. FIFO configuration or DMA.

I have another question: After I just get 494 bytes from FIFO buffer, can new data be write in FIFO buffer? And will the 18 bytes data I no read be overflow?

Hi everyone!! Thanks for all informations!! I'm trying like PJiaHeng to read Accel Mag and Gyro from a STM32F7 using SPI and DMA. Today i correctly acquire data from FIFO using "method 2" by PJiaHeng. Can anyone explain how to configure DMA to access to FIFO? Thanks a lot

[PJiaHeng]

Hi, CatInTheRain. Congratulation! About DMA operation, some STM32F7 forum would be a good platform. So I suggest you asking some operation about DMA from there. I am just familiar with STM32F4 DMA operation. In spite of this, I am also happy to communicate with you about DMA operations. I display my email in my github personal homepage.

[CatInTheRain]

Thanks a lot!! STM32F7 and STM32F4 are very similiar. My main problem is the magnetometer that stops suddenly to refresh data after 1-2 minutes. I have tried to use the FIFO to solve problem but nothing changes. Does anyone has/had the same problem?

[lasithf]

Interesting! I would like to know more about this behavior of the magnetometer.

I have come across a similar issue in the past that "locks up" the magnetometer completely after some time and cannot resolve the issue unless a power cycle. What I have done is then reconfigure MPU9250 to unhook the magnetometer and therefore I can still get the accelerometer and gyro data.

It looks to me more like an internal I2C bus lockup rather than uC to MPU9250 bus lock up.

Unfortunately not much success from Invensys contacts on how to resolve this issue.

Would you be able to recreate the issue? If so could you please provide more information?

On Wed, 9 Sep 2020 at 21:16, CatInTheRain notifications@github.com wrote:

Thanks a lot!! STM32F7 and STM32F4 are very similiar. My main problem is the magnetometer that stops suddenly to refresh data after 1-2 minutes. I have tried to use the FIFO to solve problem but nothing changes. Does anyone has/had the same problem?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/384#issuecomment-689494750, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADB6WDNZHRVW2OIR4MXL6T3SE5PXDANCNFSM4IVBB2MQ .

[PJiaHeng]

Hello, lasithf and CatInTheRain.

I also have come across a similar issue as your description. So, I wanna ask you some details to further confirm the cause of this problem:

1. Do you only connect one MPU9250 to MCU?
2. Do you use the DMP Library on your project? ( cause I deduce DMP leads to this issue )
3. Which breakout board do you use? ( I use the breakout board from Sparkfun, this design is not give a pull-up resistor in SDO pin. I am not sure whether this details can lead to this issue)

Have you considered using other types of sensors？

Regards.

[lasithf]

I have a custom PCB setup connecting one MPU9250 with the MCU (STM32) over SPI and I don't use DMP library. It's basically fill up the circular FIFO and then reading the FIFO at intervals before FIFO overflows.

[PJiaHeng]

The DMP is just get Accel and Gyro data then push to FIFO.

When we wanna get magnet data by SPI combined with internal I2C bus, we should set bit 5 of user_control register to 1. This bit is named I2C_MST_EN. From page 40 of MPU-9250 Register Map and Descriptions ( version 1.6 ), I notice a note that DMP will run when enabled, even if all internal sensors are disabled,except when the sample rate is set to 8Khz.

I deduce that the running DMP module leads to "lock up" internal I2C bus.

Have you considered the reasons for this？

[CatInTheRain]

Hello lasithf and PJiaHeng. Would you beg me for my bad english! In these two days i found an other library on github for the STM32F4 to connect one mpu9250 via SPI: this is the link and it' s working very well! This library is very useful because it shows when there is a problem on transmitting data: https://github.com/Tanba28/MPU9250-via-SPI In these two days i worked compare my old library with this and i don' t find big differences. Now i'm working with one MPU9250 from Invensense: https://www.google.com/search?q=mpu9250+drotek&source=lnms&tbm=isch&sa=X&ved=2ahUKEwi5uo_MpN7rAhXQC-wKHbnxAY0Q_AUoAnoECAsQBA&biw=1397&bih=647#imgrc=QzjuHnOsGOjHYM

So i tried many difference settings (I2C bus frequency, SPI speed, HAL_Delay...) but the Mag continue to freeze. I begin to think that there was a physic problem: i put the electronic away from my pc and also i put the mpu9250 away from all the other circuits and the magnetometer doesn't freeze after 2 minutes like before, but continue also after ten minutes. I didn' t use FIFO nor DMA.

[PJiaHeng]

Hi, lasithf. I read all related documents about DMP from Invensense website. Possibly, this situation we talked is not related with DMP.

Hi, CatInTheRain. I read the repo you mentioned. The operate method about magnet is consistent to mine.

I use stm32f4_std library on mcu rather than HAL library. It is not convenient to use the library you mentioned in my project. I will try to do it.

Do you try to connect one more mpu to mcu using the repo you mentioned? Can it work right?

I don't search the schematic diagram of mpu9250 board that you use. I guess there is issue about spi sdo pin on the mpu9250. What do you have other ideas?

[CatInTheRain]

Hi PJiaHeng, yes now i can read 2 IMUs as slave peripheral to the MCU Master!! (Without using FIFO) I have modified the repo i mentioned to read 2 different data sets and it seems working! It' s very important to set all CS GPIO to high as default value and to reset at the begin of the code the IMU to avoid WHO I AM problems ( set PWR_MGMT_1 to 0x80). I change some things in the code: there are some errors on the scale factor, I rotate the mag axis to accel and gyro axis, and finally i added the two digital low pass filters. I also tried to set the bit 6 of register 36 to 1 because someone says to me that the problem of the mag was caused by the buffer that was emptied before it even filled up. This is my sensor: https://www.amazon.it/DROTEK-IMU-10DOF-MPU9250-MS5611/dp/B01MS6Y912 Very important setting: try to reduce SPI speed! I have problems again because the second sensor still freeze... D:

[PJiaHeng]

Hi, CatInTheRain.

Thanks for providing me the purchase link which breakout board you use. Maybe the official website doesn't provide the schematic diagram, I still don't find it. Maybe there is few influence of SPI SDO pin on this situation. So I'm not considering this reason for now.

I can get the 9DOF data from 1 IMU now.(also without using FIFO) In my setting, the bit 6 of register 36 is set to 1. And I notice that there is one difference about the setting of register 55 between our repos. I don't set the bit 1 of register 55 to 1. Do you set this bit and enable the ByPass Mode? I think this setting is unnecessary for SPI. How do you think?

Now, I also have the problem as you, the second IMU freeze... The spi speed is 1MHz on my project now. Do you watch the bit3 values of register 58? I notice that the bit3 will change to 1 before the mag occur freeze. Do you have same situation?

[PJiaHeng]

When only one IMU is connected, I found some problems with the magnetometer data. Occasionally there will be 8 to 10 consecutive sets of magnetometer data that are exactly the same. Does the magnetometer data you get have this phenomenon? Another situation is when I higher the spi speed to more than 1MHz, The sensor will freeze despite I just connect one IMU to MCU.

[CatInTheRain]

Hi PjiaHeng, maybe the bit 6 of register 36 setting to 1 doesn' t solve the issue, even though I recommended it to you. Unfortunately the manual is inaccurate and I’m going to trial every day. Yes you are right the setting of ByPass Mode is unnecessary. In my project i use 843KHz for SPI but i think it's the same.
"Another situation is when I higher the spi speed to more than 1MHz, The sensor will freeze despite I just connect one IMU to MCU." Yes the same happen to me! 8 or 10 samples equals is caused because you didn't set the CONTINUOS MEASUREMENT MODE 2 on the mag. With che continuos measurement mode 1 the sample rate is 8Hz, while with the other is 100 Hz

[CatInTheRain]

It 's really frustrating: there are times that 3 minutes pass and the second IMU doesn' t freeze, and after 1 minutes it freezes. I'm getting mad. I try to swap the 2 CS so theoretically the first IMU must freeze, but i notice that after 8 minutes it doesn't freeze yet. Maybe we are near, i don't understand anything. Yesterday night i spoke to my teacher that advise to use FIFO only with the Mag. Does your FIFO works with 2 IMUs?

[PJiaHeng]

8 or 10 samples equals is caused because you didn't set the CONTINUOS MEASUREMENT MODE 2 on the mag. With che continuos measurement mode 1 the sample rate is 8Hz, while with the other is 100 Hz

Hello, maybe I didn’t describe it clearly. The magnetometer has been set to CONTINUOS MEASUREMENT MODE 2 by me always. The magnetometer data I obtain is different each time, but the phenomenon I described occurs approximately every about 10ms. (There will be 8 to 10 consecutive sets of magnetometer data that are exactly the same)

Do you analys your mag data?

I run my project on everyone IMU. It seems to work right( However it still occur situation described as above). But when I connect to one more IMUs, there are some IMUs of them will freeze after a few momemt. I think exchanging CS line do not fix out anything.

I guess the IMU freeze reason may be that the magnetometer is not working properly when only one IMU is connected to MCU. After obtaining the magnetometer data for a period of time, the magnetometer stopped updating the measurement, which caused me to get the 8~10 sets of same magnetometer data.

I deeply feel the same with you, and I think we are near to success. My FIFO does not work with 2 IMUs. I think we should focus on no FIFO&DMA situation.

Hope to have more in-depth discussion and common exploration with you to solve the problems we encountered together!

Mutual encouragement!!

[lasithf]

Re: 8-10 same mag data: Mag is slower than accel and gyro sample rate, therefore if you run at a higher sample rate, mag will copy same data to fill the sample rate gap.

This is what I've seen on my end.

Does the mag lockup fix when you power cycle?

On Sat, Sep 12, 2020, 12:23 AM PJiaHeng notifications@github.com wrote:

8 or 10 samples equals is caused because you didn't set the CONTINUOS MEASUREMENT MODE 2 on the mag. With che continuos measurement mode 1 the sample rate is 8Hz, while with the other is 100 Hz

Hello, maybe I didn’t describe it clearly. The magnetometer has been set to CONTINUOS MEASUREMENT MODE 2 by me always. The magnetometer data I obtain is different each time, but the phenomenon I described occurs approximately every about 10ms. (There will be 8 to 10 consecutive sets of magnetometer data that are exactly the same)

Do you analys your mag data?

I run my project on everyone IMU. It seems to work right( However it still occur situation described as above). But when I connect to one more IMUs, there are some IMUs of them will freeze after a few momemt. I think exchanging CS line do not fix out anything.

I guess the IMU freeze reason may be that the magnetometer is not working properly when only one IMU is connected to MCU. After obtaining the magnetometer data for a period of time, the magnetometer stopped updating the measurement, which caused me to get the 8~10 sets of same magnetometer data.

I deeply feel the same with you, and I think we are near to success. My FIFO does not work with 2 IMUs. I think we should focus on no FIFO&DMA situation.

Hope to have more in-depth discussion and common exploration with you to solve the problems we encountered together!

Mutual encouragement!!

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/kriswiner/MPU9250/issues/384#issuecomment-691124822, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADB6WDMXFXZZKTGF5XGRZDDSFIXGVANCNFSM4IVBB2MQ .

[CatInTheRain]

Hi PJiaHeng "Do you watch the bit3 values of register 58? I notice that the bit3 will change to 1 before the mag occur freeze. Do you have same situation?" No, i didn't see anything like this... I have just tried to connect only one IMU and after 2 minutes mag freeze again. I want to find out if there is a flag that warns mi that there is a problem on Mag: in this case we can set ad interrupt and we can disable and enable I2C bus, what do you think? I store data from mag (when there is only one IMU) and i didn't found equals consecutive datas, i'm sorry! Accel and gyro are running to 1KHz in your code right? Also sometimes the last WHO_AM_I Check fails but i didin' t understand why, probably i forget to reset something, i don' t know.