Failed IMU begin with error code -12

[SorabhR]

Hey,

I have DK-42670-P development board.
The spi pins are out on J4 for the development board. I have connected my esp32s3 spi pins there.
But I am unable to initialise the IMU it is failing with error code -12.
Please help if you have any idea to resolve this.

[tdk-opensource]

Thank you for opening this issue! We will look into it shortly.

Notifying @tdk-invn-oss/motion-maintainers @tdk-invn-oss/arduino-maintainers

[rbuisson-invn]

Hello @SorabhR,

Could you please you provide a trace of the SPI signals using scope or logic analyzer?
That would greatly help us providing support.

Regards,

[SorabhR]

I am sorry I don't have a logic analyser.

But I tried raw code of spi reading the who_am_i register of the imu and that is working fine.
So why is the initialisation only failing with this library?

[rbuisson-invn]

Could you please check the value you read for the who am i?

[SorabhR]

I got 0x67 for who_am_i

[rbuisson-invn]

Thanks, perfect so SPI signals integrity is OK.
Could you please share the code you use for the raw who am i read?

[SorabhR]

#include <SPI.h>

// Define pins
const
int CS_PIN = 10; // Chip select pin for SPI
const

void setup() {

// Initialize SPI

SPI.begin();

// Set CS pin as output

pinMode(CS_PIN, OUTPUT);
digitalWrite(CS_PIN, HIGH); // Set CS high initially

Serial.begin(115200);

}

void loop() {

// Select the ICM-42670-P

digitalWrite(CS_PIN, LOW);

// Send a command (example: read from a register, 0x75 is WHO_AM_I register)

SPI.transfer(0x75 | 0x80); // Send WHO_AM_I command (read bit is 1)
byte response =

SPI.transfer(0x00); // Read the response

// Deselect the ICM-42670-P

digitalWrite(CS_PIN, HIGH);

Serial.print("WHO_AM_I response: ");
Serial.println(response, HEX);

delay(1000);
}

[rbuisson-invn]

You don't use Arduino SPI.beginTransaction() method ?
What mode is the SPI? (should be MSBFIRST, SPI_MODE3)

[SorabhR]

I have used the default spi mode

[rbuisson-invn]

Could you share the Arduino sketch source code ?
At least the part initializing the device.

[SorabhR]

I have used this code only exactly
No changes this uses SPI MODE 0

[rbuisson-invn]

Do you call following lines somewhere?:
ICM42670 IMU(SPI,10);
IMU.begin();

(sorry for the terrible questions, but I need to reduce the scope to understand what could be the issue)

[SorabhR]

During the examples code of the library yes I do call it but in my raw code I do not

Infact IMU.begin only fails

[rbuisson-invn]

Do you confirm that you use 10 in ICM42670 IMU(SPI,10); ? (default is pin 8)

[SorabhR]

Yes I did that change

[rbuisson-invn]

Ok can you try to add the following line in your raw code before starting the who am i read (before digitalWrite(CS_PIN, LOW);):
SPI.beginTransaction(SPISettings(6000000, MSBFIRST, SPI_MODE3));

[SorabhR]

Okay I will try that and let you know
Any other thing also can I try as I will try things after sometime

[rbuisson-invn]

Yes sure, try other valuesfor SPI clock frequecy and SPI_MODE parameters.

[SorabhR]

Does the library use SPI3 and 6MHz clock?

[rbuisson-invn]

Yes exactly!
SPI frequency can be specified, for instance:
IMU(SPI,10,1000000);

[SorabhR]

So as far as I understand library uses SPI mode 3 what if the sensor does not work on that and only works on spi mode 0?

[rbuisson-invn]

By default the ICM42670P supports both SPI modes 0 & 3:

[rbuisson-invn]

Another possible issue, other than SPI settings, could be the delay function:
delayMicroseconds(us);
The library uses this function before reading the reset status, if this function is not correctly implemented on your platform, this read could occur too early.

[SorabhR]

I am using espcore3 in Arduino ide 2.1
If that helps you understand if delay function is implemented properly

So spi mode 0 and mode 3 both should work.

[SorabhR]

Hey
The raw code is working with spi mode 3

[rbuisson-invn]

And with SPI clock @6MHz?

[SorabhR]

Yes that's working too

[rbuisson-invn]

Ok many thanks for these tests and feedback.
So it looks like SPI works as implemented in the library...

Let's try validating the delayMicroseconds....
Could you try the following code on your platform?
Serial.println(millis());
delayMicroseconds(1000);
Serial.println(millis());

And check that the increment between the 2 println is around 1000us.

Regards,

[SorabhR]

Yeah so the difference between the two millis is of 1 which is 1000us

[rbuisson-invn]

That's correct !
So everything works separately :)
Might be a stack size issue... Do you have any idea on how to increase stack size on your platform?

Alternatively, you could modify the Documents\Libraries\Arduino\ICM42670\src\ICM42670.cpp in function spi_read, something like following, to check every parameters:
static int spi_read(inv_imu_serif* serif, uint8_t reg, uint8_t * rbuffer, uint32_t rlen) {
ICM42670* obj = (ICM42670*)serif->context;
obj->spi->beginTransaction(SPISettings(obj->clk_freq, MSBFIRST, SPI_MODE3));
digitalWrite(obj->spi_cs,LOW);
obj->spi->transfer(reg | SPI_READ);
obj->spi->transfer(rbuffer,rlen);
digitalWrite(obj->spi_cs,HIGH);
obj->spi->endTransaction();
Serial.println(obj->clk_freq);
Serial.println(rlen);
Serial.println(rbuffer[0]);
return 0;
}

[rbuisson-invn]

Could you please add Serial.println(obj->spi_cs); and Serial.println(reg);
The rbuffer[0]=0xFF means that MISO was not driven by the sensor.

[SorabhR]

10000000
1
103
10
117

Suddenly it started working but giving garbage values

[rbuisson-invn]

Hello @SorabhR ,
Your last reply shows a correct who am i read with SPI clock at 1M.
What's the garbage you are mentioning?

[SorabhR]

Hey
I change spi mode 0 in library and it started giving data

[rbuisson-invn]

Ok looks like SPI signal integrity is not so good finally.
Could you please try to write the DRIVE_CONFIG3 register to 0x3 or 0x2 ?
This will reduce the SPI slew rate, which is required to avoid crosstalk in some specific setup.

[SorabhR]

But with mode0 it is working fine so what would changing slew rate help in?

[rbuisson-invn]

If SPI signals are not fully safe you will probably have other issues later in your dev.
There should be no reason for mode 0 to work better than mode 3 (the only diff is the clock state when CS is high).

[SorabhR]

So In spi mode 0 I should change the slew rate but when I change the spimode3 will re powering both sensor and esp cause the settings to go back to factory default?

[rbuisson-invn]

The slew rate is reset at power up.
The register I pointed out changes the SPI signal form only for MISO.
So it doesn't impact write access.

[SorabhR]

So should I set that in the Imu.begin function?

[rbuisson-invn]

Yes before inv_imu_init, you could do something like:
uint8_t data = 0x03;
spi_write(&icm_serif,0x05,&data,1);

[SorabhR]

Okay

[rbuisson-invn]

Hello @SorabhR,

Any feedback on that test?

Regards,

[SorabhR]

Hey
Sorry for late reply but it didn't work only spi mode 0 is working

[kjs-eir]

@SorabhR and @rbuisson-invn any update on this issue? I am encountering the same issue, ( i have tried to change slew rate) and being trying both SPI4 and SPI3.

The error code -12 happens to me after executing status |= inv_imu_device_reset(s) in inv_imu_init()
I don't get the issue when running of the eval kit, but once i move to my PCB with ICM42670 on it, I get the error code.

[rbuisson-invn]

Hello @kjs-eir,

Could you please share any capture of the SPI signals?

Thanks and regards,

[kjs-eir]

Hi @rbuisson-invn

I have one setup with access to the SPI-bus, but this is working fine, and another setup on a PCB without access to the SPI-bus which isn't working(here i get -12 when trying to reset the IMU). I can share captures of the working SPI communication from the eval-kit, but does that make any sense?

By the way, here is how my ICM42670P is wired on the PCB:

Thanks,
Karl-Johan

[sriccardi-invn]

Hi @kjs-eir ,
Could you describe which PCBs you are using and connection between CPU and ICM42670?
Thanks.
Sebastien Riccardi

[kjs-eir]

Hi @sriccardi-invn

Sure. For my evaluation board setup I use a Psoc6 MCU (Also on a custom PCB, but with way more test-points) and the DK-42670-P eval board. The connection is made via J4, where I connect MISO, MOSI, SCLK, CS, INT1, INT2, GND. I also connect a 3.3V source from my MCU. On DK-42670-P I have a jumper on J3 between 3V3 and VDDIO. This makes me able to power the DK-42670-P with out external power, and then I can power up the ICM42670P and get IMU via SPI.

My second setup is a custom made PCB, but with the same MCU, and a ICM4670P. The connection are as shown on my previous picture, where SPI_MISO_IMU, SPI_MOSI_IMU, SPI_CLK_IMU, SPI_CS_IMU and IMU_INT are connected to the respective SPI-compatible GPIO on the MCU. IMU_WAKE is connected to a buck-boost converter, with the intension of using WOM. But here I encounter the issue with error code -12 when trying to reset the IMU.

I hope this make it easier to understand the issue, otherwise let me know.

Thanks,
Karl-Johan

[sriccardi-invn]

HI @kjs-eir ,
Between both board, you are using same CPU io for SPI ?
thanks.
Regards,
Seb

[kjs-eir]

Hi @sriccardi-invn

Yes, the same model and rev, both a PSOC6, and I am flashing the same FW image on both setup.

Thanks,
Karl-Johan

[sriccardi-invn]

HI @kjs-eir ,
Do you have a pull up on INT2 on your new board ? INT2 is open drain by default. Mayve you have no 3.3v on IMU VDDIO
Regards,
Seb

[kjs-eir]

Hi @sriccardi-invn

I have no pull-up on neither of INT1 or INT2. I can try and add one to INT1 via the configurable HW blocks in PSOC6, but doing that on INT2 is more tricky.
I have 3.3V on VDDIO, I have verified that with my multimeter.

Any other leads/ideas?

Thanks,
Karl-Johan

[sriccardi-invn]

HI @kjs-eir ,
Could you confirm that you have no other slave on the same SPI bus?
This is maybe not the rootcause but leave INT2 floating at start up will create issue on your buck-boost converter. Maybe your buck-boost converter has an internal pull up ?
Regards,
Seb

[kjs-eir]

Hi @sriccardi-invn
Yes, there is no other slaves on the SPI bus.
The buck-boost converter has no internal pull-up, but can be enable by different sources, where INT2 is one of them, and I overlook this before, but there is a 100k pull-down on INT2 .

Regards
Karl-Johan

[rbuisson-invn]

Hello @kjs-eir ,

Could you please try the following change in the ICP42670P library:

• in inv_imu_driver.c, in function configure_serial_interface, line 1486, add the following lines:
  value = 0x3;
  inv_imu_write_reg(s,DRIVE_CONFIG3, 1, &value);

[kjs-eir]

Hi @rbuisson-invn

Thanks for the input. I tried to add the lines for updating DRIVE_CONFIG3, but the issue persist. To clarify a bit more, it is when executing inv_imu_device_reset() and when trying to read the value of INT_STATUS:

/* Clear the reset done interrupt */ status |= inv_imu_read_reg(s, INT_STATUS, 1, &data); if (data != INT_STATUS_RESET_DONE_INT_MASK) status |= INV_ERROR_UNEXPECTED;

Data become 0xff, resulting in INV_ERROR_UNEXPECTED

[rbuisson-invn]

Hello @kjs-eir ,

Thanks for the feedback.
You are correct regarding the issue, this error usually happens when the SPI communication is not properly working (as this is the first check done in the driver).

The best way to proceed would be to get the SPI traces on the failing board, to understand what the issue could be.

Regards,

[kjs-eir]

@rbuisson-invn maybe this is a long shot. But the eval kit has a external pull-down on the FSYNC pin, but my setup doesn't have that and the datasheet says it ok to connect it directly to ground?

[rbuisson-invn]

Hello,

This should not be a problem.

Regards,