BMI160 firmware upload fails with BHY_CRC_ERROR

[Jet]

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.

[tonyh]

The i2c-write method (.bus_write) is matching 1:1 to Zephyr's API: https://docs.zephyrproject.org/apidoc/latest/group__i2c__interface_gaf995812f31e7bf1ea7f203905db1382...

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[] = {

  0x2a, 0x65, 0x00, 0x1a, 0x9a, 0x31, 0x1b, 0xe7, 0x00, 0x00, 0x00, 0x00,

  0x74, 0x28, 0x00, 0x00, 0xe8, 0x99, 0x7f, 0x00, 0x44, 0x19, 0x00, 0x00,

  0x68, 0x8d, 0x7f, 0x00, 0x4a, 0x26, 0x00, 0x70, 0x4a, 0x26, 0x00, 0x70,

  0x4a, 0x26, 0x00, 0x70, 0x4a, 0x26, 0x00, 0x70, 0x4a, 0x26, 0x00, 0x70,

  0x4a, 0x26, 0x00, 0x70, 0x4a, 0x26, 0x00, 0x70, 0x4a, 0x26, 0x00, 0x70,

  0x4a, 0x26, 0x00, 0x70, 0x4a, 0x26, 0x00, 0x70, 0x4a, 0x26, 0x00, 0x70,

[tonyh]

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?

[Jet]

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 ?

[tonyh]

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. 😑