BMI160: How do you properly use "softreset"?

[IDEngineer]

I'm able to configure the BMI160 to run both its accelerometer and its gyroscope at 400Hz ODR with Data Ready coming out of INT1. I'd like the ability to reset the chip if something goes wrong. There's a "softreset" command available by writing 0xB6 to the CMD register at 0x7E.

I've tried writing 0xB6 to 0x7E, but when I do the chip becomes completely unresponsive. I've included a 100mS delay after the softreset command but that doesn't fix it. I've even tried much longer delays, manually by stalling the debugger, but again that doesn't fix it.

To be precise: If I write my configuration values without first doing a "softreset" via CMD (0x7E), the BMI160 configures fine, my configuration values can be read back from the chip, the INT1 pin indicates Data Ready, and data is available by reading the Acc and Gyro registers. But if I change nothing else except precede the above sequence with a "softreset", the chip never starts working... no INT1, no changing data in the Acc and Gyro registers.

Why would resetting the chip cause an otherwise successful configuration to fail? My natural presumption was that I wasn't waiting long enough after softreset before starting to write configuration values, but no amount of delay seems to fix this.

What are the tricks to using "softreset"? Any assistance gratefully appreciated... thanks!

[bod609]

Hello. I realise this is a fairly old post but I'm having exactly the same issue on BMX160 and wonder if you found a solution?
I'm running 4-wire SPI at 8MHz (3.3V). Here is some code to show the issue:

struct bmi160_dev sensor;
sensor.id = 0;
sensor.interface = BMI160_SPI_INTF;
sensor.read = user_spi_read;
sensor.write = user_spi_write;
sensor.delay_ms = user_delay_ms;

//STEP 1: read the chip-id to show we have a connection //
uint8_t read_test=0;
while(read_test!=216)
{bmi160_get_regs(BMI160_CHIP_ID_ADDR, &read_test, 1, &sensor); }
// OUTCOME: gives read_test=0xD8 as expected //

//STEP 2: write and read some data to a random register to show the write function is working //
uint8_t data = 10;
bmi160_set_regs(0x71, &data, 1, &sensor);
bmi160_get_regs(0x71, &read_test, 1, &sensor);
// OUTCOME: gives read_test=10 as expected //

//STEP 3: soft-reset //
data = 0xB6;
bmi160_set_regs(BMI160_COMMAND_REG_ADDR, &data, 1, &sensor);
delay_ms(200);        // I tried changing this value up to 3000
bmi160_get_regs(BMI160_PMU_STATUS_ADDR, &read_test, 1, &sensor);
// OUTCOME: gives read_test=0xFF from this point onwards all reads are 0xFF //

//STEP 3: write and read some data exactly the same as before //
data = 10;
bmi160_set_regs(0x71, &data, 1, &sensor);
sensor.delay_ms(1);
bmi160_get_regs(0x71, &read_test, 1, &sensor);
sensor.delay_ms(1);
//OUTCOME: gives read_test=0xFF, not 10 as expected//

//STEP 4: read the chip-id again//
while(read_test!=216)
{bmi160_get_regs(BMI160_CHIP_ID_ADDR, &read_test, 1, &sensor); } // read_test=0xFF ...!!??
//OUTCOME: now stuck in a loop. read_test=0xFF //

For STEP 2 I also tried "bmi160_soft_reset(&sensor)" and "bmi160_init(&sensor)" (which also uses the soft-reset).
These both had the same outcome.

If anyone can see what I am missing it would be a great help.

[bod609]

So I solved this not long after posting. In my 'user_spi_write(...)' the slave select pin was being pulled up straight after writing to the sensor. This worked fine except in the case of the soft-reset as this condition during power-up sends the sensor into I2C mode. An spi_read  or rising edge did not bring it back into SPI mode.
The solution was to add a short delay (1ms) to the user_spi_write function before Slave-Select pull-up.

[o_o]

The BMI160 protocol autodetection logic is as follows:
1) After reset, part is in i2c mode.
2) Upon rising edge of CSB pin, the part will switch to SPI mode until next reset.

it is a good idea to included a dummy write to register 0x00 after each reset, to make sure the part is in SPI mode. In case you want to always use SPI, you can write the spi_en bit in Register 0x70 and back it up in the NVM, so that the part always start in SPI mode without dummy transaction. See datasheet section "Primary Interface I2C/SPI Protocol Selection"

o_o