I am trying to get the BHI160 to start. However, after uploading the RAM patch successfully the BHI160 generates an error meta event and stops working. More precisely, I can read the following sequence of bytes from the FIFO: "0xFD, 0x00, 0x00, 0xFC, 0x8F, 0x04, 0xFE, 0x04,
0x22, 0x15". According to the datasheet (Table 29), "0xFD, 0x00, 0x00" and "0xFC, 0x8F, 0x04" are timestamp events and "0xFE, 0x04,
0x22, 0x15" is a meta event signaling an error.
My question is, how to interpret the two payload bytes of this event? The datasheet states, that byte 1 contains the "Error Register" and byte 2 the "Debug State", but I cannot find any documentation on either of them.
the part is a BHI160B and the firmware is the standalone BHI160B firmware provided here: https://www.bosch-sensortec.com/media/boschsensortec/downloads/firmware/bhi160_b_firmware/20210616_u...
I tried to get it to work with the Arduino driver (https://github.com/BoschSensortec/BoschSensorHub) and a self-developed driver. The self-developed driver runs on bare-metal and does not use any Arduino related code. However, I used the communication logging feature of the Arduino driver and our custom one to compare them and they produced the same output. Finally, I compared it to the bhy1 driver (https://github.com/BoschSensortec/BHy1_driver_and_MCU_solution.git) by using a mocked I2C function, which resulted in the same sequence of I2C transactions (the mocked I2C return the correct ROM version and CRC when requested). Therefore, I reckon, the initialization sequence is fine and the I2C communication is working properly. Also, the RAM version is reported after enabling the CPU.
Also on BHI160B we are facing similar problem. Both codes - our and reference code (which is attached below) gives the same results as Josua - having communication with chip we obtain error_register = 0x22, debug_state = 0x15 error codes when reading FIFO and cannot interpret it.
Could you provide any dcoumentation or support useful to solve this problem?
Moreover, we connected to the 'Aux Interface' (it's I2C that goes outside to additional sensors but also connects FUSER with BMI160 inside BHI160B) and we see (after uploading the patch framework and setting the CPU_Run_Request flag) that FUSER is trying to communicate with BMI160 using the address 0x69 and doesn't get ACK; We also tried to communicate with BMI160 ourselves (then we did not upload the patch frames and set the CPU_Run_Request flag so that FUSER would not try to communicate with anything via the Aux Interface) at 100kHz - polling address 0x69, 0x68 or any other does not return ACK.