Bosch Sensortec Community

    cancel
    Showing results for 
    Search instead for 
    Did you mean: 

    BHI260AP, hostboot mode: Firmware Verify bit (Boot Status reg) does not fill after FW upload via I2C

    BHI260AP, hostboot mode: Firmware Verify bit (Boot Status reg) does not fill after FW upload via I2C

    Gianlucamilani
    New Poster

    Dear Community,

    I am using BHI260AP in host boot mode and I have an issue with 'Firmware Verify Done' bit of the Boot Status reg 0x25. It does not fill after FW upload via I2C in the initialization phase. Here I describe better the problem encountered

    The host MCU code is the one from the example quaternion.c in https://github.com/boschsensortec/BHY2-Sensor-API/tree/master/examples.

    At the initialization phase, the host MCU is correctly able to reset the Fuser2 core, to read the BHI260AP ID and perform other initial operations communicating via I2C to the BHI260AP, here the messages from the debug terminal. 

    BHI260/BHA260 found. Product ID read 89
    Host interrupt control
        Wake up FIFO enabled.
        Non wake up FIFO enabled.
        Status FIFO disabled.
        Debugging disabled.
        Fault enabled.
        Interrupt is active high.
        Interrupt is level triggered.
        Interrupt pin drive is push-pull.
    Loading firmware into RAM.

     

     

    As visible in the last row of the above message, the board correctly polls the Boot Status register before the FW upload, giving it the permission to start the FW upload via I2C, here below the related code rows from the BOSCH APIs:

     

    	// Check if the sensor is ready to load firmware:
            // Poll the Boot Status Register (0x25) until the Host Interface Ready bit is set
    	rslt = bhy2_get_boot_status(&boot_status, &bhy2);
    	print_api_error(rslt, &bhy2);
    
    
    	if (boot_status & BHY2_BST_HOST_INTERFACE_READY)
    	{
    		uint8_t sensor_error;
    		int8_t temp_rslt;
    		SEGGER_RTT_printf(0, "Loading firmware into RAM.\r\n");
    
    		rslt = bhy2_upload_firmware_to_ram(bhy2_firmware_image, sizeof(bhy2_firmware_image), &bhy2);
    	

     

     

    The FW writing via I2C is correctly performed (through the function bhy2_hif_exec_cmd below):

    int8_t bhy2_hif_upload_firmware_to_ram(const uint8_t *firmware, uint32_t length, struct bhy2_hif_dev *hif)
    {
        int8_t rslt = BHY2_OK;
        uint16_t magic;
    
        if ((hif != NULL) && (firmware != NULL))
        {
            magic = BHY2_LE2U16(firmware);
            if (magic != BHY2_FW_MAGIC)
            {
                rslt = BHY2_E_MAGIC;
            }
            else
            {
                rslt = bhy2_hif_exec_cmd(BHY2_CMD_UPLOAD_TO_PROGRAM_RAM, firmware, length, hif);
                if (rslt == BHY2_OK)
                {
                    rslt = bhy2_hif_check_boot_status_ram(hif);
                }
            }
        }

     

     

    But after the FW writing, the verification of the Boot Status register (0x25) that is done immediately after gives uncorrect value, since both the:

    - Firmware verification Done bit

    - Firmware Error bit

    remain not set (they are 0)

    The condition above is never satisfyed(if condition in the below code snippet) , so the error message BHY2_E_TIMEOUT is returned (see below the related part of code).

    Would you be able to suggest me a possible way to fix this error? 

    Thank you  very much

    Gianluca

            if ((boot_status & BHY2_BST_HOST_INTERFACE_READY) && (boot_status & BHY2_BST_HOST_FW_VERIFY_DONE) &&
                (!(boot_status & BHY2_BST_HOST_FW_VERIFY_ERROR)))
            {
                break;
            }
        }
    
        if (i == BHY2_BST_CHECK_RETRY)
        {
            return BHY2_E_TIMEOUT;
        }

     

    6 REPLIES 6

    I tried to decrease the variable BHY2_COMMAND_PACKET_LEN to 128 and now it seems to work fine: the error is no longer shown.

    Do you think that having decreased it will not cause any other problem in the system?

    thanks, 

    Gianluca

    Hi Gianlucamilani,

    Yes.

    Generally, the read/write length in the API cannot be greater than the maximum length supported by the host MCU hardware I2C.

    Icon--AD-black-48x48Icon--address-consumer-data-black-48x48Icon--appointment-black-48x48Icon--back-left-black-48x48Icon--calendar-black-48x48Icon--center-alignedIcon--Checkbox-checkIcon--clock-black-48x48Icon--close-black-48x48Icon--compare-black-48x48Icon--confirmation-black-48x48Icon--dealer-details-black-48x48Icon--delete-black-48x48Icon--delivery-black-48x48Icon--down-black-48x48Icon--download-black-48x48Ic-OverlayAlertIcon--externallink-black-48x48Icon-Filledforward-right_adjustedIcon--grid-view-black-48x48IC_gd_Check-Circle170821_Icons_Community170823_Bosch_Icons170823_Bosch_Icons170821_Icons_CommunityIC-logout170821_Icons_Community170825_Bosch_Icons170821_Icons_CommunityIC-shopping-cart2170821_Icons_CommunityIC-upIC_UserIcon--imageIcon--info-i-black-48x48Icon--left-alignedIcon--Less-minimize-black-48x48Icon-FilledIcon--List-Check-grennIcon--List-Check-blackIcon--List-Cross-blackIcon--list-view-mobile-black-48x48Icon--list-view-black-48x48Icon--More-Maximize-black-48x48Icon--my-product-black-48x48Icon--newsletter-black-48x48Icon--payment-black-48x48Icon--print-black-48x48Icon--promotion-black-48x48Icon--registration-black-48x48Icon--Reset-black-48x48Icon--right-alignedshare-circle1Icon--share-black-48x48Icon--shopping-bag-black-48x48Icon-shopping-cartIcon--start-play-black-48x48Icon--store-locator-black-48x48Ic-OverlayAlertIcon--summary-black-48x48tumblrIcon-FilledvineIc-OverlayAlertwhishlist