Bosch Sensortec Community

    Showing results for 
    Search instead for 
    Did you mean: 

    BHI260 problem uploading firmware via I2C

    BHI260 problem uploading firmware via I2C


    We have a custom board with the BHI260 interfaced to a Nordic NRF ARM based MCU via I2C however the I2C fails to respond after sending several packets of data.

    I can read and write the host registers successfully and these are all left at their default states (I2C operation).

    I have followed the startup and nitialisation procedure from the BHI260 programmers manual and the boot register has it's Host Interface Ready bit set.

    I  now attempt to upload the Bosch_SHUTTLE_BHI260_BMM150.fw firmware to the device by writing the HOST Interface  "Upload to program ram"  command  to host register 0x00 (the command stream DMA  register) with the length field set as the number of 32 bit words in the firmware followed by NO STOP.  I then attempt to send the firmware 16 bytes at a time with NO STOPs in between until the last packet but only two lots of 16 bytes are received by the device the third is NAK'd for no apparent reason.

    Here is an I2C trace captured at the BHI260 pins using a logic analyser, where the first line is my command header followed by lines 1-3 which contain groups of 16 bytes I am sending the last of which is NAK'd preventing me from sending more: 

    Start, h50 [ h28 | WR ], h00, h02, h00, h60, h6B,
    Restart, h50 [ h28 | WR ], h2B, h66, h00, h00, h00, h00, h5A, h17, h3A, h9E, h7E, hFB, h5C, h68, hD5, hC0,
    Restart, h50 [ h28 | WR ], h7C, h27, hF4, h0A, hF4, hD0, h65, h08, h67, h4D, h72, hF4, hA0, h56, hB4, hF4,
    Restart, h50 [ h28 | WR ], h07, h64, h7E, h6E, hEF, h83, h00, hDE, h00, h00, h00, h00, h39, h4A, h39, h6B NAK, Stop

    This all appears to be correct and the data that is sent matches the hex in the firmware file.

    Just in case this is BHI260 processing issue I reduced the I2C clock speed to 100K and I have tried inserting delays between packet sends but this had no effect.

    For completeness I have added a scope trace of the I2C data clock, this also appears fine. 

    Are there any known issues uploading firmware via the I2C interface? I notice your BYP2  examples only use SPI and not I2C and there do not appear to be any examples that I can find using I2C.

    9 REPLIES 9

    Community Moderator
    Community Moderator

    You can download Sealea logic analyer SW (version 1.2.18) from the following link to open the pattern i shared last time.   This is free SW.

    For example code,  you can download the COINES SW tool from our website:

    This tool includes our sensor API as well as example code.   

    The default interface is SPI,  i change it to I2C.   you need to replace the bhy2_hal.c under folder "COINES\v2.2\sensorAPI\bhy2\bhy2_hal" 

    And the example code "bhy2_rotation_vector.c" under "COINES\v2.2\examples\c\bhy2\rotation_vector".  


    At the same time, we are trying to reproduce your issue at our platform,  can you tell me your exact MCU type and HW platform information?  

    Thanks for the logic analyser trace software link, with this I have been able to see the difference in our traces. We have I2C repeated starts between packets of firmware data that we send whilst your trace does not show this - your firmware appears to be a continuous transmit burst stream.

    Please could you confim if this is an issue for the BHI260? And if so do you have any suggestions, other than removing the repeated starts as our platform Nordic NRF52840 does not support transmit burst mode as you appear to be using.

    Community Moderator
    Community Moderator

    I tried to capture a new I2C wave form with the example code i given to you.  

    In this new log, i cut the FW download into small piece.   Each package is 44 bytes.   

    it still works fine.  

    In my log,  after one package, we send STOP, then START,  but in your code,  you send directly REPEAT START.  i think both should be working fine since it follows I2C standard.  

    One thing you need to care about,  after sending one package,  you need to send again the device address,  then followed by command register address 0x00,  then the rest of FW package.  

    You can find details in the example code with COINES package which i also shared in previously.  

    As far as i know,  we had also tried with NRF52840 plus our BHI260AB before which have no issue and FW download works perfectly.  

    After checking your trace I could see the main problem was that we were not sending the register id at the start of each separate firmware "packet". We had some other internal errors but this was the main one regarding the firmware upload.
    I think this was partly because the description in the datasheet in section 5.2.1 item 7 says not to resend the firmware upload id which I took to include not sending the reg address and the firmware length. I would suggest that this is changed to clarify the reg address should still be sent.

    Also in the data sheet section 5.2.1 there is no mention of being able to transmit data in the way you have in your trace - this section only describes TX burst transfer which is why we spent so much time thinking this problem was caused because we had added in repeat starts between firmware data sections. This is a reasonable assumption for us to make because there are many  devices out there that only accept burst tx transfer. I would recommend clarififying this fully in section 5.2.1 so that others don't have the same problems as we have had.

    Many thanks for your help on this

    Community Moderator
    Community Moderator

    Thanks for your comment.  

    I will feedback this to the internal team to see if we can fix it in later version of the datasheet.