BMA456 FIFO issue

[keizerr]

Hello there,

I am currently trying to read out the BMA456 accelerometer data using FIFO.
It works great until I enable BMA456 features. After I write the configuration file into BMA456 (even without features settings), the FIFO is never supposed to work then, although while debugging it can be seen that the configurations of FIFO are OK.
Can anyone please help me?

Regards,
Roman.

[keizerr]

Excuse me, 
I have already made a brief description of my  application in this post:
https://community.bosch-sensortec.com/t5/MEMS-sensors-forum/Possible-bug-in-BMA456-driver/m-p/46299#...
and as it might be apparent, I decided to focus on hearable features of BMA456.
So, I would like to know, what information about my application do you exactly need? What shall be added to this description in order to start a conversation about the issues I raised on the forum?

Regards,
Roman

[BSTRobin]

Hello keizerr,

I setup SW code based on github code "https://github.com/BoschSensortec/BMA456-Sensor-API/blob/master/examples/bma456/generic/fifo_waterma...", BMA456 FIFO works.
Please refer attachment example code.

[Weaver]

Hi BSTRobin and keizerr,

I've run into the same issue. I can read the tap detection when bma456h_write_config_file(&bma) is included, but not the FIFO. When this command is omitted, the FIFO operates, but the tap detection does not. I suspect the error is in my configuration. Although I am setting the FIFO interrupt to map to BMA4_INTR2_MAP, it appears on BMA4_INTR1_MAP (an indication that the config file needs to be written, I think).

keizerr, have you had any luck in solving this issue?

BSTRobin, unless I am mistaken, the code sample you provided is for the BMA456 rather than BMA456h.

I would be happy to use the BMA456 feature set, except that I was unable to get tap detection working using it. The project comprises a wearable that intermittently records high resolution accelerometer data and uses tap detection for user inputs. Do you have any advice on which feature set would be preferred?

Cheers,

Michael.

[Weaver]

Regarding the INT1 vs INT2 for FIFO usage in the API: 

Ok, no sure if the API definitions have been fully updated or not, but after a deeper look at function "bma4_map_interrupt" in "bma4.cpp", it seems it can only target the INT1 output. Here is the originally provided interrupt masks and mapping function:

/**\name    INTERRUPT MASKS        */
#define BMA4_FIFO_FULL_INT                       UINT16_C(0x0100)
#define BMA4_FIFO_WM_INT                         UINT16_C(0x0200)
#define BMA4_DATA_RDY_INT                        UINT16_C(0x0400)
#define BMA4_MAG_DATA_RDY_INT                    UINT16_C(0x2000)
#define BMA4_ACCEL_DATA_RDY_INT                  UINT16_C(0x8000)


/*!
 *  @brief API sets the interrupt to either interrupt1 or
 *  interrupt2 pin in the sensor.
 */
int8_t bma4_map_interrupt(uint8_t int_line, uint16_t int_map, uint8_t enable, struct bma4_dev *dev)
{
    int8_t rslt;
    uint8_t data[3] = { 0, 0, 0 };
    uint8_t index[2] = { BMA4_INT_MAP_1_ADDR, BMA4_INT_MAP_2_ADDR };

    /* Check the dev structure as NULL */
    rslt = null_pointer_check(dev);

    if (rslt == BMA4_OK)
    {
        rslt = bma4_read_regs(BMA4_INT_MAP_1_ADDR, data, 3, dev);
        if (rslt == BMA4_OK)
        {
            if (enable == TRUE)
            {
                /* Feature interrupt mapping */
                data[int_line] = (uint8_t)(int_map & (0x00FF));

                /* Hardware interrupt mapping */
                data[2] = (uint8_t)((int_map & (0xFF00)) >> 8);     // <------------------------ does not allow for INT2
            }
            else
            {
                /* Feature interrupt un-mapping */
                data[int_line] &= (~(uint8_t)(int_map & (0x00FF)));

                /* Hardware interrupt un-mapping */
                data[2] &= (~(uint8_t)((int_map & (0xFF00)) >> 8)); // <------------------------ does not allow for INT2
            }

            rslt = bma4_write_regs(index[int_line], &data[int_line], 1, dev);
            if (rslt == BMA4_OK)
            {
                rslt = bma4_write_regs(BMA4_INT_MAP_DATA_ADDR, &data[2], 1, dev);
            }
        }
    }

    return rslt;
}

The 'int_line' argument has no influnce on the data being sent to 0x58 (INT_MAP_DATA), data[2]. After changing  'int_map' from 0x0200 to 0x2000 ( see datasheet below ) the INT2 mapping is successful, so it is basically ignored.

From the datasheet (Rev 3.0_112020):

The function seems to be modifiable to correct this by simply changing the amount of bit shifting based on the line selected, as follows:

// ...

/* Hardware interrupt mapping */
data[2] = (uint8_t)((int_map & (0xFF00)) >> (4 * (2 - int_line)));     // Shift 8 bits for INT1, 4 for INT2

//...

Please correct me if I have misunderstood the correct use of this API function though. 🙂

 Cheers,

Michael.

[BSTRobin]

Hello Weaver,

The code I provided has the same function as the code on GitHub and works normally.
BMA456 also support TAP detection, you could see example code from here: https://github.com/BoschSensortec/BMA456-Sensor-API/blob/master/examples/bma456/generic/tap.c