Magnetometer setup issues

[ChrisHul]

Hi
Although not implementing the library, I have used it as a reference for setting up and reading the icm20948. I appreciate your work because it is one of the most elaborated and easy to read driver software out there.

It seems the main culprit with the module is the magnetometer and how to access it. Trying to read the "who i am" variable didn't seem to work at all. Then after testing different options occasionally but by no means reliably. Adding delays before reading SLV0_DATA didn't seem to help at all.

Then I decided to do the setup and register read operations through SLV4 instead - and magic occurred. I2C_SLV4_CTRL has a trigger bit for read/write operations and will reset after completed operation that can be polled. I still use SLV0 for the sensor readings.

Now it work like a charm - every reset and power-up. This may solve your inconsistent magnetometer start-ups.

Btw, your myIMU.getMagValues() method approach may no be very commendable. It will return a pointer to memory that has been returned to the heap (free()) since it's a dynamic variable that gets out of scope with "return". It will probably work almost 100% but I would rather see myIMU.getMagValuesmagValue(&magValue).

Keep up your good work, Chris

[wollewald]

Hi @ChrisHul , that sounds promising. I will try another time to solve the issue using your solution. Thank you!!
Wolfgang

[wollewald]

Hi @ChrisHul, I followed your advice to do the settings of the magnetometer by using it as SLV4. And I also still use it as SLV0 for data reading. It works! Hurray! Since it was a sporadic issue (at least on my side) I tried it very often under various conditions, e.g. different MCUs, I2C/SPI, reconnecting to power, rebooting and uploading again and again. Feels like I did this 1000 times.

I don't think you can imagine how thankful I am for your tip! I spent so many hours before.

What I don't exactly understand is why using the magnetometer as SLV0 was causing an issue. Somehow register reading and writing interfered with the data reading. But why?

The other issue with myIMU.getMagValues() is basically easy to solve. But the new version would not be compatible with programs written for the fomer versions. This might trigger a lot of questions. On the other hand, I would like to remove this unclean code. I will think about this.

Best wishes!

[ChrisHul]

Hi again,
That was quicker than I thought it would be. "Another time" sounded like weeks away.

SLV4 is different from other SLVs in that the EN flag is specified to RESET upon completed transfer. The problem with the others is that you will never know when operation will occur because it is conditioned by the ODR (sampling rate) and the magnetometer readings are dependent on the Gyro and Acc ODR (as stated in the magnetometer ODR parameter). Maybe there is a delay in the start-up of the Gyro and the Magneto readings only start after a while. The datasheet is rather crappy when it comes to the timing.

About the myIMU.getMagValues() I just wanted to make you aware of the problem. I got in trouble myself for returning pointers to dynamic structures and arrays. Being a tutor you probably want to stay safe with the advice you give.

Another thing I discovered when dealing with the Gyro is that it seems to have an internal bias correction on start-up. On highest sensitivity it sometimes meant that it picked up an out of range value (2^15) and my readings on that axis stayed there until a new power-up. Disabling and enabling with a delay in between solved that problem. PWR_MGMT_2 = 0x3F, delay, PWR_MGMT_2 = 0. I saw someone else had done the same thing (other repository).

And you don't have to thank me for anything. You have done more to the community than I ever will, so I am just happy to contribute with anything I can.

Schönen Abend und auf Wiederhören, Chris

[medisoft]

Hi @ChrisHul

I'm wondering if the current code in the version 1.1.11 has that change, because I'm facing blocking on the resetMag() function.

And the resetMag function is calling writeAK09916Register8_SLV4(AK09916_CNTL_3, 0x01);, that sometimes blocks on an eternal while

while(readRegister8(3, ICM20948_I2C_SLV4_CTRL) & ICM20948_I2C_SLVX_EN){;}
So i'm not sure if your proposed idea is implemented or not.

Thank you

[ChrisHul]

Hi @medisoft

You should be running 1.2.0 if you have the writeAK09916Register8_SLV4() in your code.
I'm not running Arduino (but rather Raspberry pi pico SDK), so I didn't propose the code myself.
I think our friend Wolfgang made the changes in a rush. I created a fork of the repository on my account () with some cleanup. I can't try it out. Maybe you can be so kind and try it before I make the pull request? That would be appreciated.

[ChrisHul]

Some how the link to the fork got lost:
https://github.com/ChrisHul/ICM20948_WE/tree/main

[wollewald]

Hi, currently I can't try myself. It looks like I've overdone it with the sport and will have to stay in hospital for a few days. Very bad timing.

[ChrisHul]

No worries. We'll see if we can sort it out.
Take care. Recover soon.

[wollewald]

I am back.

@ChrisHul, I tested you forked version and it works fine. Thank you! The only thin I would do additionally is deleting the function
void ICM20948_WE::enableMagDataRead_SLV4(uint8_t reg){}
since it is not needed anymore.

However I had also tested my former version and it also worked without any problem. So, I suggest we wait for the feedback from @medisoft.

[ChrisHul]

Good to know you're back on your feet @wollewald
Sure. It shouldn't really block because the flag is stated to reset after completed operation. I think the fact that (1.2.0) set the 'reg'-register after setting the triggering flag in the write-method may have upset the module. You could also intertwine some sort of timeout in the while-statement to stop the system from hanging, but you don't seem to do a lot of error-testing anyway.
Let's hope @medisoft comes back with a result of his testing.

[wollewald]

@ChrisHul , I tested version 1.2.0 on an ESP32 and Arduino Nano using I2C and SPI. Resets, power on, new uploads. Overall several hundred times. It did not hang a single time. Difficult to solve a problem which does not occur on my side.

[samotgameing]

@wollewald
I've also encountered this issue these are the troubleshooting steps I've taken:

• uncommitted the delay at the start of startup(); - failed
• committed out Magnetometer setup and printing code - failed
• adding delay after Serial.begin and after myIMU.init - failed

hardware I'm using is a ESP32 DEVKIT tested with v1.2.0
Code that has been tested:
ICM20948_06_angles_and_orientation - passed
ICM20948_04_calibration - passed
ICM20948_02_gyroscope_data - passed
ICM20948_01_acceleration_data - passed

ICM20948_05_acc_gyr_temp_mag_data - failed
ICM20948_03_magnetometer - failed

ERROR message from all: "ICM20948 does not respond"
now testing ChrisHul's fork

[samotgameing]

@wollewald
troubleshooting steps I've taken:

• use of ChrisHul's fork - success

hardware I'm using is a ESP32 DEVKIT tested with ChrisHul's fork
Code that has been tested:
ICM20948_06_angles_and_orientation - passed
ICM20948_04_calibration - passed
ICM20948_02_gyroscope_data - passed
ICM20948_01_acceleration_data - passed

ICM20948_05_acc_gyr_temp_mag_data - passed
ICM20948_03_magnetometer - passed

[wollewald]

@ChrisHul, since your version has solved the issue at least for @samotgameing , I would like to implement your version. Could you submit a pull-request?

[ChrisHul]

Done. Also deleted the dead code that you mentioned, so you just have to merge it I guess.