BMI270 API/github lib v2.53.2: bmi2_get_config_file_version(...) does not report anything

[stephanhd]

I am using the BMI270 and want to differentiate/check/report/document the config file type and version.

int8_t bmi2_get_config_file_version(...)

looks good BUTinside bmi2_get_config_file_version()

other internals are called which does not find the "markers" that they looks for ...

The "Problem" is here:

uint8_t bmi2_extract_input_feat_config(struct bmi2_feature_config *feat_config, uint8_t type,
const struct bmi2_dev *dev){
/* Variable to define loop */
uint8_t loop = 0;

/* Variable to set flag */
uint8_t feat_found = BMI2_FALSE;

/* Search for the input feature from the input configuration array */
while (loop < dev->input_sens){
if (dev->feat_config[loop].type == type) {
*feat_config = dev->feat_config[loop]; //this is never reached
feat_found = BMI2_TRUE;  
break;
}

loop++;
}

/* Return flag */
return feat_found;
}

Neither for gesture nor for context based config file....

Is this a misunderstanding from my side what int8_t bmi2_get_config_file_version(...) should do or ...it is a bug?🐛

Would be nice to determine the type of initialization (gesture || context) as well...

Thanks and kind regards, Stephan

[Vincent]

Where and how you call the function  bmi2_get_config_file_version?

The function bmi2_extract_input_feat_config is used quite offten in BMI270 API.  when you want to get the configure of desired feature,  you will use this funciton.  and it works properly. 

So i don't think the function itself has bug inside. 

[stephanhd]

Dear Vincent,

we want to use bmi2_get_config_file_version() as part of the init procedure.

Reduced code-snippet:

/* Initialize bmi270: Check, Upload MC, ... */
//rslt = bmi270_init(&bmi2_dev);
rslt = bmi270_context_init(&bmi2_dev);

/* Get Version of MC, ... */
rslt = bmi2_get_config_file_version(&wbmi270Data.CONTROL.ConfigVersionMaj, &wbmi270Data.CONTROL.ConfigVersionMin, &bmi2_dev);

/* SelfTest ACC */
rslt = bmi2_perform_accel_self_test(&bmi2_dev);

BMI270 is working perfect, but bmi2_get_config_file_version() does not report anything since the inner loop:

if (dev->feat_config[loop].type == type) {
*feat_config = dev->feat_config[loop]; //this is never reached
feat_found = BMI2_TRUE;  
break;
}

does not find the marker that its looking for...

Best, Stephan

[Vincent]

I go through the API again. 

During initialize of sensor, we will give the following table content to created device structure.  

In bmi2_get_config_file_version, we use BMI2_CONFIG_ID to look up the table.  but actually it is not defined in table with coresponding page id. 

So the return will be 0.   

This means your function call to this will not return correct value. 

In case you want to distingruish if you initiliaze as context image or activity image,  you can try to check if the dedicated configure type is existing and able to read out.  For example:  BMI2_NO_MOTION is not included in context image,  if you are not able to find the feature type after initialize,  then you are using context image. 

Hope this solution will help you. 

const struct bmi2_feature_config bmi270_feat_in[BMI270_MAX_FEAT_IN] = {
{ .type = BMI2_MAX_BURST_LEN, .page = BMI2_PAGE_1, .start_addr = BMI270_MAX_BURST_LEN_STRT_ADDR },
{ .type = BMI2_CRT_GYRO_SELF_TEST, .page = BMI2_PAGE_1, .start_addr = BMI270_CRT_GYRO_SELF_TEST_STRT_ADDR },
{ .type = BMI2_ABORT_CRT_GYRO_SELF_TEST, .page = BMI2_PAGE_1, .start_addr = BMI270_ABORT_STRT_ADDR },
{ .type = BMI2_AXIS_MAP, .page = BMI2_PAGE_1, .start_addr = BMI270_AXIS_MAP_STRT_ADDR },
{ .type = BMI2_GYRO_SELF_OFF, .page = BMI2_PAGE_1, .start_addr = BMI270_GYRO_SELF_OFF_STRT_ADDR },
{ .type = BMI2_NVM_PROG_PREP, .page = BMI2_PAGE_1, .start_addr = BMI270_NVM_PROG_PREP_STRT_ADDR },
{ .type = BMI2_GYRO_GAIN_UPDATE, .page = BMI2_PAGE_1, .start_addr = BMI270_GYRO_GAIN_UPDATE_STRT_ADDR },
{ .type = BMI2_ANY_MOTION, .page = BMI2_PAGE_1, .start_addr = BMI270_ANY_MOT_STRT_ADDR },
{ .type = BMI2_NO_MOTION, .page = BMI2_PAGE_2, .start_addr = BMI270_NO_MOT_STRT_ADDR },
{ .type = BMI2_SIG_MOTION, .page = BMI2_PAGE_2, .start_addr = BMI270_SIG_MOT_STRT_ADDR },
{ .type = BMI2_STEP_COUNTER_PARAMS, .page = BMI2_PAGE_3, .start_addr = BMI270_STEP_CNT_1_STRT_ADDR },
{ .type = BMI2_STEP_DETECTOR, .page = BMI2_PAGE_6, .start_addr = BMI270_STEP_CNT_4_STRT_ADDR },
{ .type = BMI2_STEP_COUNTER, .page = BMI2_PAGE_6, .start_addr = BMI270_STEP_CNT_4_STRT_ADDR },
{ .type = BMI2_STEP_ACTIVITY, .page = BMI2_PAGE_6, .start_addr = BMI270_STEP_CNT_4_STRT_ADDR },
{ .type = BMI2_WRIST_GESTURE, .page = BMI2_PAGE_6, .start_addr = BMI270_WRIST_GEST_STRT_ADDR },
{ .type = BMI2_WRIST_WEAR_WAKE_UP, .page = BMI2_PAGE_7, .start_addr = BMI270_WRIST_WEAR_WAKE_UP_STRT_ADDR },
};

[stephanhd]

Dear Vincent,

>In case you want to distingruish if you initiliaze as context image or activity image, you can try to check if the dedicated configure type is existing and able to >read out. For example: BMI2_NO_MOTION is not included in context image, if you are not able to find the feature type after initialize, then you are using >context image.

Sounds like a plan - we will do so.

Regarding plans: is there a regular update of the API/MicroCode planned in near future?
We are not planning to OTA the MicroCode in the final product - is this a risk from your point of view?

And: is there any possibility to share some details about the "microcode" aka config-file; 8kByte is a lot of stuff: what is included there?

Kind regards, Stephan