Bosch Sensortec Community

    cancel
    Showing results for 
    Search instead for 
    Did you mean: 

    BMI270 Config File

    mullercw
    Member

    Re: BMI270 Config File

    I'm using the SPI bus to access the BMI270. The device can reply to the DEVICE_ID register 0 with 0x24. I can monitor the SPI bus and it seems ok and other devices on the same bus function. When I try toload the config_file array from the Github into the BMI270_REG__INIT_DATA register the INTERNAL_STATUS show "Not Init". The INTERNAL_STATUS shows 0x00 (Not Init) and when I read back from the BMI270_REG__INIT_DATA, it is all the same random value for every register (2B, 2B, 2B.. or 1F, 1F, 1F...).

    I see that I have to load this 8k file to even get basic accelerometer data. 

    Does this basic procedure below seem correct?

    ----------------------------------

    //load file to configure
    bmi270_writeregister(dev, BMI270_REG__INIT_CTRL, 0);

    //set Address to 0 
    bmi270_writeregister(dev, BMI270_REG__INIT_ADDR_0, 0);
    bmi270_writeregister(dev, BMI270_REG__INIT_ADDR_1, 0);

    //load array file

    bmi270_write(dev, BMI270_REG__INIT_DATA, (uint8_t*)bmi270_config_file, sizeof(bmi270_config_file));

    //Write init CTRL to 1 showing config loaded.
    bmi270_writeregister(dev, BMI270_REG__INIT_CTRL, 1);

    vTaskDelay(300);
    bmi270_readregister(dev, BMI270_REG__INTERNAL_STATUS, &val);

    ----------------------------------
    Can I change bmi270_config_file to {1,2,3,4,5,6,7,8};, load it and should I be able to read this 1-8 back as a test to see if I can write to the device? When I do it, I get the same random data, like this register is locked or something.

    The INTERNAL_STATUS shows 00, not 02 which is failed to load. What is the difference in status?

    tkobet
    New Poster

    Re: BMI270 Config File

     I don't see that this one is marked resolved, so I'll try adding onto this since I'm having similar issues.  We're working with a TI CC2640R2, and while we are able to fit the 8k config file into flash with the rest of the application, RAM is very limited, and we cannot integrate the BMI270 API.  The firmware is following the init/config file download procedure from the datasheet, but INTERNAL_STATUS always reports initialization error.  I have verified the bmi270_config_file array that I pasted into our firmware source code is identical to that in BMI270.c.

    The chip reports its ID correctly, so the SPI interface looks good.  The SPI clock speed is 10 MHz.  The full 8k file is transferred with a single burst write (0x5E followed by the 8k of config data in one SPI transfer).

    Since the main micro can be reset for debugging without resetting the BMI270, I have included a soft reset (0xB6 to register 0x7E) as part of application startup when initializing the BMI270.  I have added a 4ms delay after the soft reset command before issuing the command to disable advanced power saving to start the dowload process.

    A few questions:  Is any particular delay required between each command issues over SPI, aside from the 450 us delay after disabling advanced power saving?

    Are there any register values to check that might provide some information on the nature of the failure?

    Is it generally considered more reliable to transfer the file in chunks vs. a single burst?

    We are working with a custom board that is extremely small, and I am not sure we will be able to attach wires to the SPI bus for logic analyzer probes, but this has not been ruled out.

    tkobet
    New Poster

    Re: BMI270 Config File

    It appears the timing is very tight on the init sequence.  If I code all the SPI transfers one immediately after the other, I can get the download to succeed (INTERNAL_STATUS reports init_ok).  If I put the SPI transfers into a generic transfer function, introducing function call over head between each step, the download fails, and INTERNAL_ERROR reports "long processing time, processing halted".

    The problem I'm having now is that if I'm running in the debugger, I can get the sequence to succeed one time.  If I restart the firmware in the debugger, the result reported in INTERNAL_STATUS is always not_init (0).  The download sequence seems to only work after a power cycle, even though a soft reset is included before starting the sequence.

    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