Bosch Sensortec Community

    cancel
    Showing results for 
    Search instead for 
    Did you mean: 
    SOLVED

    bmi2.c v/s bmi270.c in BMI270_API

    bmi2.c v/s bmi270.c in BMI270_API

    punitjain8695
    Member

    I'm interfacing the BMI270 shuttle board with TI's TM4C1294NCPDT based evaluation board. It's a 32-bit arm-based microcontroller.

    I'm trying to use BMI270_API.

    I've read the value at register address 0x00. it is 0x24. This was done using the bmi2_ois.c file, using the function:

    int8_t bmi2_ois_get_regs(uint8_t ois_reg_addr, uint8_t *ois_reg_data, uint16_t data_len, struct bmi2_ois_dev *ois_dev)

    Now, I was going ahead with initializing the sensor so that I can get to my target of reading acceleration and gyro values. For this, I understand (as of now), that I have to use the function defined in bmi270.c:

    int8_t bmi270_init(struct bmi2_dev *dev)

    ---

    This requires two variations, first is, the dev structure is different, which I have defined separately. and another, inclusion of the bmi270.c file during the compilation.

    This throws error of declaration being incompatible for

    static int8_t null_ptr_check(const struct bmi2_ois_dev *ois_dev);  in bmi2_ois.c

    and static int8_t null_ptr_check(const struct bmi2_dev *dev); in bmi270.c

    which is obvious since both of these work on different dev structures of different kinds.

    I then tried the following:

    I removed the bmi2_ois.c from the compilation includes which results in the errors for unresolved symbols for these:

    bmi2_get_gyro_cross_sense
    bmi2_sec_init

    Again, I tried to include bmi270.c and bmi2.c, which results in multiple definitions of several functions.

    Am I doing something incorrectly? What is the proper procedure to do this?

     

    11 REPLIES 11

    Hello punitjain8695, 

     

    We don't have the document about API hierarchy, but simply say that bmi270.c is bmi270 dependent source and bmi2.c is more general code for our bmi2 products, but necessary. 

    As you said, common.c is interface files so if you implement all in your main file it's not necessary. 

    However, I don't recommend to optimize bmi2.c and bmi270.c if you are not familiar with our API. 

    Here is my Arduino code for BMI270 without common.c 

    At least you understand what you need to modify it. 

    Thanks, 

    I had tried modifying the bmi270.c file, commented out the functions whose definitions were clashing with the ones in bmi2.c. The compilation went fine, but then bmi270_init gave a result of 0xfd, which is -3. According to bmi2_defs.h, it corresponds to BMI2_E_DEV_NOT_FOUND.

    I checked further, it is due to chip_id mismatch. I am not initializing the intf_ptr present in the bmi2_dev structure? Are these related?

     

    I tried to understand your codes, the files you're using for bmi270.c and bmi2.c are different from the ones in the AP. I see that you've removed all functions except the bmi270_init from the bmi270.c file. and you've defined many more functions in the bmi2.c, which are not there in the API's bmi2.c file.

     

    I think I'm on a completely incorrect track right now. Using an API shouldn't have been this difficult. Is there some method I can do this the way it is supposed to be done?

     

    Edit:

    I tried to debug why the bmi_init function was returning -3 as rslt.

    turns out, in the function int8_t bmi2_sec_init(struct bmi2_dev *dev) in bmi2.c, there is:

    /* Read chip-id of the BMI2 sensor */
                rslt = bmi2_get_regs(BMI2_CHIP_ID_ADDR, &chip_id, 1, dev);
    
    if (rslt == BMI2_OK)
                {
                    /* Validate chip-id */
                    if (chip_id == dev->chip_id)
                    {
                        // ...
                    }
                    else
                    {
                        /* Storing the chip-id value read from
                         * the register to identify the sensor
                         */
                        dev->chip_id = chip_id;
                        rslt = BMI2_E_DEV_NOT_FOUND;
                    }
                }

    The issue is, when it reads the chip ID here, it reads it as 0x00. I have a hunch that the dummy byte configuration is not correct. Initially, when I was reading the chip ID using bmi_get_regs(), it required me to handle the extra SPI dummy byte in my reg read code. which shouldn't be the case if the mode is SPI.(the API has the appropriate code to handle that additional byte, if it's configured as SPI.)

    I think, initially, it is going ahead with dummy byte = 0, and then somewhere down the line, it is being reconfigured as 1. so, when it reads the first byte from the received buffer, it is the dummy byte, which is 0x00.

    I'm unsure how to solve this issue.

    Hello punitjain8695, 

     

    Please check initializing bmi270. 3. Quick Start guide. 

    https://www.bosch-sensortec.com/media/boschsensortec/downloads/datasheets/bst-bmi270-ds000.pdf

    At first, you should read 0x24 from register 0x00. 

    If you can't, then you need to check i2c. 

    Please check my example and modify your code properly. 

    Thanks, 

    I tried implementing the whole startup sequence using bmi270_init();

    I figured out that the error was, that I was not clearing the RX buffers after transmitting in legacy mode. But that is taken care of now.

    As of now, the bmi270_init runs fine (the return for that function is BMI_OK (0x00)). and the register at 0x21, has it's LSB as 1, which means that the initialization has been successful.

    But when I try to run this: bmi270_get_sensor_config(), it gets stuck in the first SPI read function.

    From bmi270_get_sensor_config(), it goes to bmi2_get_sensor_config(), and then to get_accel_config() and then to bmi2_get_regs(), where it terminates with an error to Fault dead loop.

    I tried debugging the error, and found out that the size of the data space allocated for the read function is not enough for the read to be done.

     

    Edit:

    I checked further, the size of the array is sufficient. The issue is something different, it seems.
    It is getting stuck when reading two bytes from Register 0x40, so, 0x40 and 0x41. I tried reading those two registers directly by using the bmi2_get_regs() function, and it is reading the registers properly. The values are @0x40: 0xa8; @0x41: 0x02;

     

     

    I  checked further, it happens that, whenever I assign anything related to "struct bmi2_sensor_data sensor_data", The code compiles, but results in runtime error and ends up in Fault_ISR while loop.

    even a part of the code which is simple as this:

     

                // Assign accel and gyro sensor.
                sensor_data[ACCEL].type = BMI2_ACCEL;
                sensor_data[GYRO].type = BMI2_GYRO;

     

    throws an error. The code is able to read the chip ID, however. but fails in the bmi270_init().

     

    My guess is, this structure contains a uint8_t type variable and a union. As in C, union's size will be limited to the max of the sized of it's elements, it is not able to work properly. Should I convert all of the unions to struct types?

    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