Reading Honeywell MPRLS02.5BG0000SA Pressure Sensor Over SPI on STM32H753I-EVAL2

[BitwiseBen]

Hi everyone,

I’m integrating the Honeywell MPRLS02.5BG0000SA pressure sensor via SPI with an STM32H753I-EVAL2 board and encountering some inconsistent behavior. 

---

Setup Details

• Sensor: Honeywell MPRLS02.5BG0000SA

• Breakout Board: Based on MPRLS0015PA0000SAB, but the sensor was manually replaced with the 02.5BG variant

• MCU: STM32H753I-EVAL2 (Cortex-M7)

• Interface: SPI

• SPI Clock Speed: 50 kHz (as required by Honeywell for proper communication)

• Chip Select (CS): Manually toggled via custom GPIO (not using STM32’s hardware NSS)

• Power: 3.3V supply with decoupling capacitors and pull-ups as recommended

• Tools: Logic analyzer to validate SPI signals and sequences

---

Partial Success

• I can reliably communicate with the sensor only when I call __HAL_SPI_ENABLE() immediately before pulling CS low and starting the SPI transaction, and then drive CS high after the transaction ends.

• This workaround lets me receive pressure data occasionally.

---

Inconsistent Issues

Despite partial communication success, I encounter the following problems:

1. Memory Integrity Check Failures: I receive errors indicating data corruption or “memory integrity” problems.

2. Unresponsive Behavior: At times, SPI responses are all 0xFF or garbage data, even though CS, SCK, MOSI, and MISO lines look correct on the logic analyzer.

3. Inconsistent Power-on Behavior: The sensor does not always respond after power-up unless the enable/CS sequence is handled very specifically.

4. Unclear Timing Dependencies: I suspect something related to SPI peripheral enable/disable timing is affecting communication, especially around CS transitions.

---

SPI Configuration (STM32 HAL)

I’ve tried various configurations in STM32CubeMX / HAL init:

• Mode: Master

• Direction: 2-line

• Data Size: 8-bit

• CPOL: Low

• CPHA: 0 (tried 1 as well)

• Baud Rate Prescaler: To get ~50 kHz

• First Bit: MSB

• NSS: Software (custom GPIO used)

Let me know if you’ve found a specific configuration that works better for Honeywell SPI devices.

---

What I’m Looking For

1. Has anyone seen similar behavior where __HAL_SPI_ENABLE() is required before toggling CS or initiating SPI?

2. Any idea why omitting __HAL_SPI_ENABLE() causes partial communication or memory errors?

3. What is the most reliable sequence to initialize and communicate with the MPRLS02.5BG0000SA?

4. Are there known quirks or undocumented timing issues with this particular variant (02.5BG)? Even though it's similar to the 0015PA in protocol, it’s a different pressure range.

5. Any working SPI HAL code samples or sensor timing diagrams for stable non-blocking communication?

---

I can share logic analyzer traces and SPI transaction logs if that helps. I’d also be happy to post my code if someone wants to take a look.

Thanks in advance for any tips or direction!
— 0xAbhi

[TDK]

HAL takes care of enabling the peripheral. Perhaps show some traces where MISO is correct but received data is wrong. Ensure signal integrity is there--no long wires. Perhaps show a picture of the setup.

Here are two examples with nonblocking SPI communication:

STM32CubeH7/Projects/NUCLEO-H743ZI/Examples/SPI at master · STMicroelectronics/STM32CubeH7

[Pavel A.]

@BitwiseBen How have you connected the SPI device? Which pins are used? From UM2198 table 69, no pins are assigned to a SPI by default. Using for SPI a pin that is already connected to something else is not a good idea.

Examples of SPI use can be found in the Cube firmware package for 'H753/H743  based boards. Note that SPI in STM32H7 differs from earlier MCUs (F4 and so on) so be careful not to copy-paste code made for other MCUs.