Bosch Sensortec Community

    Showing results for 
    Search instead for 
    Did you mean: 

    BMI270 SensorAPI (v2.71.8 & v2.86.1) bmi270_init() Requires Several Min to Complete

    BMI270 SensorAPI (v2.71.8 & v2.86.1) bmi270_init() Requires Several Min to Complete

    Occasional Visitor


    I am following the Any Motion Interrupt example from here:

    I am able to interact with the BMI270 over SPI just fine. As per examples, I am loading the default config file that is included within bmi270.c (see const uint8_t bmi270_config_file[]):

    I have played with burst write sizes and have gone as fast as 256 bytes on writes. Works fine and loads the config file quick enough (a couple of sec).

    After the config file is loaded (within bmi270_init()), the SensorAPI lib (bmi270.c I believe) changes the power mode to low (writes 0x03 into 0x7C). After about 2 min (when using SensorAPI v2.71.8) or about 25 sec (when using SensorAPI v2.86.1), reg 0xA1 is read and then the power mode is changed to normal power mode (writes 0x02 into 0x7C). I am referencing datasheet sections 2 and 3 for my understanding of power modes (see flowcharts) as the register doc for 0x7C is not clear (to me anyway). After returning to normal power mode, bmi270_init() finally returns and I am able to correctly read the chip ID. I do not notice any other delays. I have not tried interacting with the BMI270 after reading the chip ID as I would like to resolve this delay first.

    Some notes:

    1. See above for the reduced delay when using SensorAPI v2.71.8 vs v2.86.1 (2-3 min delay becomes approx 25 sec).
    2. Logged config file contents writes match the contents within bmi270.c (i.e. the values that I am writing match those in the .c file) - so I am confident that I am writing data ok, but I am not reading back the file to confirm it.
    3.  The implementation of bmi270_init() does not seem to follow section 4.4. In this section, the INTERNAL_STATUS register (0x21) is checked as the final step within intialization (but this is not done within SensorAPI's bmi270_inin() and no power changes are described).
    4. There are several register reads (e.g. 0xD9, 0xFC ...) that occur that are outside of the documented register range (ends at 0x7E). What are these?
    5. Critically - how can I get rid of this delay or reduce it to a few sec?

    My spi read/write logs are below - showing significant reg values being read/written during initialization. The point of delay is shown. Note that after the delay, register reads of 0xA1 and 0xFC are made before the power mode is restored to normal (0x02 write to 0x7C). The log below reflects bmi270_init() implementation in both versions of SensorAPI referened within this post.

    [bmi2_spi_write] write register 0x5B with length 2
    [bmi2_spi_write] write register 0x5E with length 16
    Data: 80 2E 00 C1 80 2E 00 C1 80 2E 00 C1 80 2E 00 C1
    [bmi2_spi_read] read register 0xD9 with length 2
    [bmi2_spi_write] write register 0x59 with length 1
    Data: 01
    [bmi2_spi_read] read register 0xFC with length 2
    [bmi2_spi_write] write register 0x7C with length 1
    Data: 03

    Several sec or min delay here (depending on SensorAPI version) ....
    [bmi2_spi_read] read register 0xA1 with length 2
    [bmi2_spi_read] read register 0xFC with length 2
    [bmi2_spi_write] write register 0x7C with length 1
    Data: 02
    [bmi2_spi_write] write register 0x2F with length 1
    Data: 00
    [bmi2_spi_read] read register 0xB0 with length 17
    [bmi2_spi_read] read register 0xFC with length 2
    [bmi2_spi_write] write register 0x7C with length 1
    Data: 03
    [xtag_bmi2_init] DEBUG: About to get chip ID.
    [bmi2_spi_read] read register 0x80 with length 2
    [xtag_bmi2_init] DEBUG: BMI270 read chip ID 36
    [xtag_bmi2_init] DEBUG: BMI270 initialized.
    [user_init] Debug: BMI270 IMU enabled. IMU Wake may be used.


    1 REPLY 1

    Community Moderator
    Community Moderator

    Hi markj,

    Thanks for your inquiry.

    We suggest that you use a logic analyzer to capture SPI hardware waveforms, which can show the actual host accessing SPI data of BMI 270 and the delay during communication. Instead of observing through printing information, as printing itself can cause delays.
    Additionally, from your print information, it appears that some registers are not used on the data sheet of BMI270, such as registers 0xA1, 0xB0, etc. in your print information. This requires checking if your code or printing is correct.

    Additionally, I have attached the waveform of BMI270 SPI communication captured through Saleae for your reference.