Bosch Sensortec Community

    Showing results for 
    Search instead for 
    Did you mean: 

    BMI160 firmware upload fails with BHY_CRC_ERROR

    BMI160 firmware upload fails with BHY_CRC_ERROR



    I have setup where is nRF52840+Zephyr and BHI160B is connected to with i2c @400kHz. BMM150 is connected to BHI160B.

    Most of the BHI160-codes are from:

    Firmware for upload with bhy_initialize_from_rom() is: Bosch_PCB_7183_di03_BMI160_BMM150-7183_di03.2.1.11696_170103.h

    Normal booting sequence is going fine, but bhy_get_crc_host(v_crc_host_u32) returns v_crc_host_u32 = 0xFFFFFFFF. Return value itself is BHY_SUCCESS.

    During the firmware upload (and only time) INT is going low for 5ms, which is abnormal as FW is not uploaded yet. Normally INT reason is not read here, but bhy_get_chip_status() in ISR claims that firmware_idle and no_eeprom are set by 1.

    Overall boot and FW upload:


    Begin of FW upload:


    End of FW upload:


    Any thoughts, what can be wrong here?

    11 REPLIES 11

    Occasional Contributor

    Hi Sir:

        Because there is no length limitation to write FW in bhi160b I2C read and write function when initialize,  you should split the length of read and writing in your interface function. Did you achieve this feature by yourself or it comes with this function for nRF52840 I2C function?

       You can print bhy_get_crc_host() value and v_crc_from_memory_u32 value to observe whether they are the same value to know FW upload successful or not. For example:     PRINT("bhy_get_crc_host=0x%x v_crc_from_memory_u32=0x%x\n\r",v_crc_host_u32,v_crc_from_memory_u32);

       And after load fw, you also need to check two interrupt pin change, which you know from example code. And then the BHI160B initialization is successful. Before fw is loaded, you don't need to care the interrupt pin.


    The i2c-write method (.bus_write) is matching 1:1 to Zephyr's API:

    Here is the begin of FW upload. Are these byte orders as expected? I also pasted the begin of FW array.


    const unsigned char bhy1_fw[] = {
      0x740x280x000x00, 0xe80x990x7f0x000x440x190x000x00,


    Just soldered more measurement pins. Seems that BHI160 starts some I2C activity to BMM150 direction when INT goes low.

    Big picture of FW upload, upper I2C is from nrf52<->BHI160, lower I2C is between BHI160<->BMM150.


    I2C between BHI160<->BMM150 zoomed in. Bus is running @88kHz and its seems scanning something, leading always to NAK. According to our understanding BMM150 I2C address is 0x10.


    Does this giving any glue?

    Occasional Contributor

    Hi Sir:

          After fw load, it will check BMM150 whether to connect or not due to this fw with BMM150. Meanwhile, I2C between BHI160<->BMM150 and I2C between BHI160<->BMI160(the IMU of internal BHI160B ) are the same I2C lines.

          If you doubt BMM150 interference, maybe you can remove BMM150 and use a new fw without BMM150.

           Did you have the external pull-up resistor to VDDIO on the ASCK and ASDA of the BHI160B in order to enable proper I2C communication?


          I have the example code of STM32 platform, would you like to referenc it ?




    Root cause found as we tried the same config with ESP. Here are two screencaptures of reset-command, upper nrf52 (fails), lower ESP (works). Nrf52 sends device address before data and BHI160 might not recognize even the reset cmd as INT won't go low.

    Now have to find how I can get nrf52 I2C to make similar sequences than ESP. 😑