Bosch Sensortec Community

    Showing results for 
    Search instead for 
    Did you mean: 

    BMI08x config file loading, when not using data sync -- mandatory or not?

    BMI08x config file loading, when not using data sync -- mandatory or not?



    I have found different statements about whether using bmi08a_load_config_file, which transfers a 6 KiB binary object to the sensor using reserved registers, is a mandatory initialization step, before reading accelaration data, or not:

    @BSTRobin states  that loading the config file is a mandatory step before getting data.

    In another post, @Mark2018 writes:

    5. The config file contains the configuration for the sync feauture, the feature will not work without loading that config into the sensor. But the configuration does not effect the quality of the sensor signals, the sensor works fine without the configuration.

    This suggests that loading the config file is not mandatory, if one doesn't need data synchronization. It also appears from my own tests with a BMI088, that I can read acceleration data out of the sensor, even without loading the config file.

    Since the download of that config data utilizes registers documented as "reserved", I would find it helpful if the data sheets could be updated with a short explanation about the config file and feature configuration functionality and the exact conditions, when it should/must be used. Also, there exist tables like the one in this reply, that I could not find in recent datasheets (2021/Nov and 2022/Jan) or the Design Guide .
    In this context, in the Github driver, bmi08a.c in line 2888 regarding reserved registers ACCEL_INIT_CTRL/ACCEL_INTERNAL_STAT contains the comment

    /* Wait till ASIC is initialized. Refer the data-sheet for more information */

    but the actual information in the data sheets appears to be missing.

    BTW, does loading the 6 KiB config file alter the sensor in a permanent way, e.g. by some flash like mechanism? Or is the change lost after removing power? 


    8 REPLIES 8

    Community Moderator
    Community Moderator

    Hello knieriem,

    We usually recommend loading configuration files. The configuration file is loaded into the ram of the sensor and will be lost when the power is turned off.

    Hi BSTRobin,

    thanks for the clarification. I'm now always loading the config file during initialization, even when not using data sync resp. not using the gyro part. It works well, so I was able to release the first version of my firmware with added BMI08x support yesterday (both BMI085 or BMI088, whichever is available).

    One more question to parameter read_write_len, which is involved in writing the config file: At various places, like bmi08x_defs.h, line 1121, I'm reading "maximum supported length is 32". Apparently also lengths like 128 bytes work well on both BMI085 and BMI088. Perhaps the maximum of 32 bytes was a restriction on other sensor types. But I stick with 32 for the nonce.
    By the way, in the example code you attached below, read_write_len is first set to 46, but later overwritten with 32, before load_config_file is called. At the first location there is also the comment: "Supported length depends on target machine", which gives a hint why it also appears to work with 128.

    Community Moderator
    Community Moderator

    Hello knieriem,

    "Supported length depends on target machine" means: SPI peripheral is a part of host MCU. When MCU writes the configuration file, the actual data is sent to sensor by SPI peripheral, so read_write_len depends on the maximum length supported by SPI peripherals.

    Hello BSTRobin,

    thank you for the quick response, and the explaination.

    What I also wanted to highlight, though, is that the official driver, in bmi8x_defs.h, contains a comment: "maximum supported length is 32". This suggests that it is a restriction of the driver or the sensor device, which isn't true: The driver, and BMI085/8 devices support read_write_len of more than 32, even 128 bytes. So perhaps it would be a good idea to adjust this comment in the driver, as the information "maximum supported" apparently does not apply in this case.