Bosch Sensortec Community

    cancel
    Showing results for 
    Search instead for 
    Did you mean: 

    BMM150 problems with the BLE at STM32WB

    BMM150 problems with the BLE at STM32WB

    jorgazam
    Established Member

    Hi, my name is Jorge.

    I'm currently working with an STM32WB5MMG, which has Bluetooth LE 5.2 connectivity. In the current version of the project, it's working with two Bosch sensors. The BMI088 with accelerometer and gyroscope, and the BMM150 with a magnetometer.

    I've been working with the sensors through SPI communication in the same SPI2 port of the MCU. The operation mode works obtaining data by a data ready interrupt. Each sensor works at a different data acquisition frequency, so it can measure data at different frequencies. The BMM150 sensor has a forced mode that allows to work at higher frequencies, so it's currently configured so it can obtain the measured data from the 3 sensors at 400Hz.

    The problems started when I enabled BLE on the MCU. The project works fine for a while, until it suddenly disconnects from the device connected via Bluetooth. The MCU doesn't seem to notice that it has been disconnected for a moment, so if the mobile device requests reconnection, it reconnects. The problem is that the time it takes to disconnect seems to be completely arbitrary, in different tests it seems that it can take between 30 seconds and 40 minutes to have a disconnection.

    I've noticed that the problem seems to come from the BMM150. When this sensor is disconnected from the MCU, the BLE communication seems to work fine with only the other sensor. The BMM150 has initialization and data request functions via SPI. If I try to just initialize the sensor, without even requesting data, the BLE disconnection happens anyway.

    I've tried different boards and the same problem occurs on all of them. I have also tested with different mobile devices. I have tried to work with timers instead of interrupts, the problem I see is that I have no control over the BLE communication. The only conclusion I reached is that the problem is using the same SPI for both sensors, although through breakpoints I've seen that the operation is sequential, so the interrupts should not be at the same time.

    Right now I don't know if it's something completely normal that can happen with BLE, but I'm running out of ideas to try other tests and find where's the problem. Thank you in advance.

    5 REPLIES 5

    BSTRobin
    Community Moderator
    Community Moderator

    Hi jorgazam,

    Did you use different GPIOs of MCU to control the CS pin of the sensor respectively? During SPI communication, you can only enable the CS of one sensor and disable the CS of another sensor.

    jorgazam
    Established Member

    Yes, each sensor is using a different pin for each select chip.

    if (*select == 0) {
    HAL_GPIO_WritePin(ACCEL_CS_GPIO_Port, ACCEL_CS_Pin, GPIO_PIN_RESET); // NSS low
    } else {
    HAL_GPIO_WritePin(GYRO_CS_GPIO_Port, GYRO_CS_Pin, GPIO_PIN_RESET); // NSS low
    }

    HAL_SPI_TransmitReceive(&hspi2, &addr, rdBuffer, len+1, 50);
    while(hspi2.State == HAL_SPI_STATE_BUSY);

    if (*select == 0) {
    HAL_GPIO_WritePin(ACCEL_CS_GPIO_Port, ACCEL_CS_Pin, GPIO_PIN_SET); // NSS high
    } else {
    HAL_GPIO_WritePin(GYRO_CS_GPIO_Port, GYRO_CS_Pin, GPIO_PIN_SET); // NSS high
    }
    memcpy(reg_data, &rdBuffer[1], len);

    As you can see in the code, each CS goes to a different GPIO which is enabled or disabled before and after SPI communication is made. The CS of the magnetometer is in a different common file, but the operation of the SPI is the same.

    BSTRobin
    Community Moderator
    Community Moderator

    Hi jorgazam,

    The GPIO of MCU controls the CS pin of the sensor respectively, which is no problem. The SPI communication of the sensor itself is not directly related to Bluetooth. If Bluetooth will disconnect, you can set the interrupt priority of Bluetooth higher than that of reading data, and see it again.

    jorgazam
    Established Member

    Hi BSRobin,

    We've already tried everything, changing interrupt priorities, using timers, changing the MCU clock settings... I've also asked on the ST forums and the problem apparently is happening with this particular sensor, so right now it's a complete mystery that I can't figure out why this sensor causes these problems with BLE.

    The only options we have are hardware solutions, such as using the other SPI of the MCU, or using the I2C, the problem is that the board is already mounted, so a new design would have to be made. I appreciate your help, but definitely the problem doesn't seem to come from the SPI communication, but from the sensor.

    In another discussion in this same forum I 've also had problems with the threshold of the same sensor that I'm not able to resolve. Is there another magnetometer with similar characteristics that uses SPI or I2C that we can test as well?

    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