Skip to main content
Associate
April 20, 2026
Solved

BNO085 I2C with STM32H7A3 via SH2 library — stuck at 44Hz but ESP32 achieves 1.2ms read time

  • April 20, 2026
  • 2 replies
  • 254 views

Hi everyone,

I am working on a project using BNO085 IMU sensor and STM32H7A3ZIT6Q. I have a single sensor working but stuck at 44Hz. The same sensor with SparkFun library on ESP32 achieves 1.2ms read time. I need help understanding why and how to match ESP32 performance on STM32.

Hardware:

  • NUCLEO-H7A3ZI-Q (STM32H7A3ZIT6Q, Cortex-M7 @ 280MHz)
  • Adafruit BNO085 breakout board
  • I2C on PB8 (SCL), PB9 (SDA), PC0 (INT pin)
  • P0 and P1 tied to GND (I2C mode, address 0x4A)

Software:

  • STM32CubeIDE with HAL
  • Official CEVA SH2 library from github.com/ceva-dsp/sh2
  • REPORT_INTERVAL_US = 2500 (targeting 400Hz)
  • SH2_ROTATION_VECTOR (9-axis full quaternion)

STM32 performance achieved so far:

  • I2C 400kHz polling: 28Hz, read_ms = 32ms
  • I2C 1MHz Fast Mode Plus: 44Hz, read_ms = 19ms
  • INT pin wait inside sh2_hal_read(): still 44Hz, read_ms = 19ms

ESP32 performance with same sensor and SparkFun SH2 library:

  • read time: 1.2ms
  • Data rate: close to 400Hz

This is a huge difference. 19ms on STM32 vs 1.2ms on ESP32 with the same SH2 library underneath.

Current STM32 sh2_hal_read implementation:

static int sh2_hal_read( sh2_Hal_t *self, uint8_t *pBuffer, unsigned len, uint32_t *t_us ) 
{
 uint32_t timeout = HAL_GetTick() + 100;
 while (HAL_GPIO_ReadPin(GPIOC, GPIO_PIN_0) == GPIO_PIN_SET)
 {
 if (HAL_GetTick() > timeout) return 0;
 }
 HAL_StatusTypeDef status;
 status = HAL_I2C_Master_Receive( &hi2c1, BNO085_ADDR, pBuffer, len, 100 );
 if( status != HAL_OK ) return SH2_ERR_IO;
 *t_us = HAL_GetTick() * 1000;
 return len; 
}

Key observation: ESP32 SparkFun library reads 4 byte header first, then reads payload in 32 byte chunks with INT pin check between each chunk. Our STM32 reads entire packet in one HAL_I2C_Master_Receive call. Not sure if this is the cause of the difference.

What I have tried:

  1. I2C 400kHz to 1MHz Fast Mode Plus — improved from 28Hz to 44Hz
  2. INT pin wait inside sh2_hal_read() — no improvement
  3. Direct pin polling in main loop — no improvement

Questions:

  1. Why does ESP32 achieve 1.2ms at 400kHz I2C while STM32 takes 19ms at 1MHz?
  2. Is the bottleneck in HAL_I2C_Master_Receive vs ESP32 Wire implementation?
  3. Has anyone implemented a proper sh2_hal_read() for STM32H7 that achieves fast read times?
  4. Has anyone used I2C DMA with SH2 library on STM32H7? What improvement did you see?
  5. Is SPI the only reliable path to 200Hz+?

Edited to apply source code formatting - please see How to insert source code for future reference.

Best answer by Andrew Neil

https://learn.sparkfun.com/tutorials/how-to-use-an-oscilloscope/all

https://courses.physics.illinois.edu/phys524/fa2023/phys524_units/2/2.pdf

 

This post has a good illustration of the effects of pullup value (too high; too low) on the I2C waveform.

2 replies

Andrew Neil
Super User
April 20, 2026

What pullups are you using?

Have you looked at the I2C lines with an oscilloscope and/or logic analyser to see what's actually happening on the wires?

A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.
Associate
April 20, 2026

No can u please guide me how to do that I am new to the filed, I ma not aware how to do that 

Andrew Neil
Super User
April 20, 2026
A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.
Associate
May 22, 2026

WhatsApp Image 2026-05-04 at 3.24.22 PM.jpeg

WhatsApp Image 2026-05-04 at 4.10.45 PM.jpeg

WhatsApp Image 2026-05-04 at 4.10.38 PM.jpeg

Oscilloscope Capture — BNO085 + STM32H7A3, I2C1 @ 1 MHz

Scope: Tektronix TBS1022 | Date: 4-May-26 16:12

Channel settings:

  • CH1 (yellow): 2.00 V/div
  • CH2 (cyan): 2.00 V/div
  • Timebase: 5.00 ms/div (50 ms total window)
  • Trigger: CH1 rising edge @ 1.60 V
  • Scope-measured frequency: 43.25 – 43.46 Hz

What is visible on CH1 (yellow trace):

The yellow trace sits at a steady HIGH level for most of the window. It then drops sharply to LOW for a short duration, then returns to HIGH. This pattern repeats twice within the 50 ms window. The scope's auto-frequency measurement reads the period of this repeating HIGH-LOW-HIGH cycle as approximately 43.4 Hz.

What is visible on CH2 (cyan trace):

The cyan trace shows alternating regions. In some regions it is flat and quiet, sitting at a steady level. In other regions it becomes a dense, rapidly oscillating hash — this is the I2C clock toggling at 1 MHz, which is too fast to resolve individually at the 5 ms/div timebase so it appears as a filled block of activity. Within the 50 ms window, there are multiple such active blocks separated by quiet flat sections.

Spatial relationship between CH1 and CH2:

The transitions on the yellow trace (CH1) and the active hash blocks on the cyan trace (CH2) occur in the same regions of the time window. The quiet flat sections on CH2 correspond to the periods where CH1 is sitting steadily HIGH.

Andrew Neil
Super User
May 22, 2026

Your scope has a USB socket for a Flash Drive on the front:

AndrewNeil_0-1779436654176.png

You will be able to capture screenshots to this.

This will give much better results than photographs!

A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.