New Chat
  • Slides
  • Websites
  • Docs
  • Deep Research
  • Sheets
  • Agent Swarm
Kimi Code
Kimi Claw
Chat History
  • Get App
  • About Us
    • Visit Moonshot AI
    • Kimi Platform
    • Features
    • Terms of Service
    • Privacy Policy
  • Language
  • User Feedback

Dual BNO086 SPI Failure

Hi everyone, I’m working on a wearable embedded system using two SparkFun BNO086 IMUs connected to an ESP32-S3 (XIAO ESP32-S3) over SPI, and I’m running into a persistent issue when both sensors are connected simultaneously. System Overview MCU: ESP32-S3 (dual-core, SPI2 bus) Sensors: 2 × SparkFun BNO086 (Qwiic breakout) Interface: SPI (shared bus) SPI configuration Shared: SCK: GPIO7 MISO: GPIO8 MOSI: GPIO9 Per sensor: IMU1 → CS=GPIO3, INT=GPIO4, RST=GPIO43 IMU2 → CS=GPIO5, INT=GPIO6, RST=GPIO44 Problem Description Each IMU works perfectly individually. However, when both are connected: THIGH initializes successfully SHIN fails during beginSPI() very quickly (~30 ms) What I Already Tried 1. Proper SPI initialization sequence CS pins set HIGH before SPI.begin() Both sensors reset simultaneously: RST LOW → 50 ms → RST HIGH → wait 200 ms 2. Bus isolation logic Before initializing each sensor: Verified other sensor CS is HIGH Added debug logs to confirm 3. Inter-sensor delay Added 150 ms delay between initializing THIGH and SHIN 4. Verified SPI mode configuration PS0 and PS1 are soldered HIGH on both sensors (SPI mode confirmed) -Has anyone successfully run two BNO086 sensors on the same SPI bus? -Is SPI officially recommended over I2C for multi-sensor setups in dynamic/wearable environments? -Any known hardware quirks when using multiple BNO08x devices together? Thanks
Searching for BNO086 SPI Multi-Device Compatibility and Issues
The user is asking about a specific hardware issue with two SparkFun BNO086 IMUs on a shared SPI bus with an ESP32-S3. They have a very detailed technical question about embedded systems.
Let me analyze the problem:
  1. Two BNO086 IMUs on shared SPI bus with ESP32-S3
  2. Individual operation works, but together the second one fails during beginSPI()
  3. They have proper CS isolation, reset sequencing, delays, and SPI mode configuration
Key questions they want answered:
  1. Has anyone successfully run two BNO086 on same SPI bus?
  2. Is SPI recommended over I2C for multi-sensor wearable/dynamic environments?
  3. Any known hardware quirks with multiple BNO08x devices?
I should search for information about:
  • Multiple BNO086/BNO080 on same SPI bus
  • Known issues with BNO08x SPI multi-device setups
  • SparkFun BNO086 SPI multi-sensor configurations
  • ESP32-S3 SPI bus limitations with multiple devices
Let me do a web search to find relevant information.
I'll search for information about multi-BNO086 SPI configurations and known issues.
Search
multiple BNO086 SPI bus same microcontroller BNO08x two sensors SPI shared bus issue SparkFun BNO086 multi IMU SPI initialization problem ESP32-S3 SPI multiple slaves BNO086
25 results
ESP32 S3 SPI Multiple Devices Cause Missing Data on First Transmit
The search results are very helpful. Let me analyze what I found:
  1. Very relevant: Result is a SparkFun community post from April 26, 2026 (yesterday!) with the EXACT same issue - "Dual BNO086 over SPI (ESP32-S3 plus) One sensor fails init when both connected". This is essentially the same user or someone with the exact same problem. This is extremely relevant.
  2. GitHub issue : "BNO080 not working on shared SPI bus (multiple SPI slaves)" - This is a known issue from 2021 where BNO080 fails when another SPI device is on the same bus. The BNO080 receives an empty header after first H_INT and stops talking. This is very relevant.
  3. GitHub issue : "Library: Can't initialize two BNO086 on one I2C bus" - Shows that there are known library issues with multiple BNO086 sensors even on I2C with multiplexer. The second sensor to initialize fails.
  4. SparkFun community : Another user with 8 BNO086 on I2C multiplexer, second sensor fails initialization.
  5. ESP32-S3 SPI multiple devices issue : "ESP32-S3 SPI with multiple devices missing data" - Known ESP32-S3 issue where multiple SPI slaves cause missing data on first transmit. This is a chip-level issue.
  6. ESP32-S3 SPI buses : Important info about ESP32-S3 having FSPI (SPI2) and HSPI (SPI3), no VSPI. Also mentions GPIO 35-37 issues with octal PSRAM.
Let me open the most relevant result to see the discussion.
Fetch URLs
Investigate BNO086 SPI Issues on ESP32‑S3 with SparkFun HAL
The URL open failed. Let me search for more specific information about the BNO086 SPI shared bus issue and also look at the SparkFun library implementation to understand potential issues.
Key observations from search results:
  1. - Exact same issue posted yesterday on SparkFun forums
  2. - BNO080 known issue on shared SPI bus from 2021
  3. - Library issue with multiple BNO086 on I2C
  4. - ESP32-S3 specific issue with multiple SPI devices
The user's problem is very specific:
  • ESP32-S3 with SPI2 bus
  • Two BNO086 on shared SPI
  • First initializes, second fails during beginSPI()
  • ~30 ms failure time
Known issues:
  1. BNO08x has a quirk where it may drive MISO/POCI line even when CS is deasserted (not tri-stated properly), causing bus contention
  2. The SparkFun BNO08x library may have issues with multiple instances because of how the CEVA SH2 HAL is implemented - it might use global/static state
  3. ESP32-S3 has known issues with multiple SPI slaves where first transaction can be corrupted
  4. The BNO086 requires proper RST and INT handling, and the library's hal_wait_for_int() may cause issues
Let me search for more specific information about BNO08x MISO tri-state behavior and the SparkFun library's HAL implementation.
Search
BNO086 MISO tri-state SPI bus contention SparkFun BNO08x library static HAL multiple instances BNO08x SPI CS deasserted MISO drive CEVA SH2 SPI multiple slaves same bus
33 results
Driver Modification for Multi-Instance with ESP32‑S3 Bug Workaround and Reset Timing
Now I have very good information. Let me synthesize what I've found:
  1. Exact same issue on SparkFun community : Someone posted the exact same problem yesterday (April 26, 2026) - "Dual BNO086 over SPI (ESP32-S3 plus) One sensor fails init when both connected". This confirms this is a real, reproducible issue.
  2. Historical BNO080 SPI shared bus issue : From 2021, BNO080 fails when another SPI device shares the bus. The BNO080 receives an empty header after first H_INT and stops talking. This suggests the BNO08x family has a known issue with shared SPI buses.
  3. Library-level issue with multiple BNO086 : On I2C, the SparkFun library can't initialize two BNO086 sensors - the second one always fails. This suggests the library may have static/global state issues in the CEVA SH2 HAL that prevent multi-instance operation regardless of bus type.
  4. ESP32-S3 specific SPI issue : Known bug where ESP32-S3 with multiple SPI slaves has corrupted first transaction. This is chip-specific and affects the S3 but not original ESP32.
  5. BNO08x SPI timing
    : The datasheet shows SPI mode 3 (CPOL=1, CPHA=1), max 3MHz. Also shows tcsso (CS to MISO out) max 31ns, and MISO hold after CS (tcssoh) 7.4ns. The key thing is that the BNO08x uses CEVA's SHTP protocol.
  6. MISO tri-state issue , , : Some SPI devices don't properly tri-state MISO when CS is deasserted. This is a well-known issue with certain SPI peripherals.
  7. PJRC forum discussion : Important finding - the SparkFun library uses the CEVA Sensor Hub driver, and there are issues with hal_wait_for_int() causing problems. A workaround was found by modifying enableReport() to skip the int wait on Teensy.
Now let me think about the root causes:
Potential Root Causes:
  1. BNO08x MISO not tri-stating: The BNO08x might not properly release the MISO (POCI) line when CS is deasserted, causing bus contention when two are on the same bus. This is a hardware quirk.
  2. SparkFun library static/global HAL state: The CEVA SH2 HAL used by the SparkFun library likely has global/static variables that prevent multiple instances from working correctly. When you create two BNO08x objects, they might share HAL state.
  3. ESP32-S3 SPI multi-slave silicon bug: The ESP32-S3 has a known issue where the first transaction to a slave after switching CS can be corrupted . This could cause the initialization sequence to fail.
  4. SHTP protocol initialization timing: The BNO08x uses SHTP which has a specific initialization sequence involving H_INT and reset. Having two devices on the same bus might cause interrupt line confusion or the library might not handle multiple INT pins correctly.
  5. PS0/WAKE pin conflict: In SPI mode, PS0 is also the WAKE pin. If both sensors are being initialized simultaneously or if the library drives WAKE incorrectly, there could be conflicts.
Recommendations to test:
  1. Check MISO tri-state behavior: Use a scope or multimeter to check if the non-selected BNO086 is driving the MISO line. If so, add tri-state buffers (74HC125) on each MISO line, enabled by the respective CS.
  2. Separate SPI buses: Use ESP32-S3's two available SPI buses (FSPI/SPI2 and HSPI/SPI3) instead of sharing one bus. The ESP32-S3 has FSPI and HSPI available .
  3. Use I2C with multiplexer: Though the user asked about SPI, I2C with a TCA9548A multiplexer is a common approach, though there are also library issues there .
  4. Library modification: Check if the SparkFun library's HAL has static state. The CEVA driver might need modification for multi-instance.
  5. Workaround for ESP32-S3 bug: The known ESP32-S3 issue suggests duplicating the first SPI operation as a workaround.
  6. Reset sequencing: Try holding both in reset, release THIGH first, initialize fully, then release SHIN reset and initialize.
  7. CS timing: Ensure CS is held high for sufficient time between devices. The BNO08x needs CS setup/hold times.
Let me formulate a comprehensive answer addressing all three questions and providing actionable debugging steps.
Structure:
  1. Direct answer - Yes, this is a known issue
  2. Root cause analysis (3 likely causes)
  3. SPI vs I2C recommendation for wearables
  4. Hardware quirks summary
  5. Actionable fixes/workarounds
  6. Diagnostic steps
I should be careful to cite sources properly.
This is a known, reproducible issue — someone posted the exact same configuration (dual BNO086 over SPI on ESP32-S3) to the SparkFun forums yesterday , and the BNO08x family has a history of failing when another SPI slave shares the bus .
Here is a breakdown of the root causes and how to move forward.

1. Why the second sensor fails

There are three overlapping failure modes at play:

A. BNO08x MISO/POCI bus contention (hardware quirk)

The BNO08x datasheet does not explicitly guarantee that the MISO (POCI) pin enters a high-impedance state immediately when CS is deasserted
. In the 2021 GitHub issue for the BNO080 (same SHTP architecture), the sensor stops responding as soon as another SPI slave is connected to the shared MISO line . If the non-selected BNO086 continues to drive the bus even with CS HIGH, the selected device cannot communicate.

B. SparkFun library static HAL state (software limitation)

The SparkFun BNO08x library wraps CEVA’s SH2 Sensor Hub driver, and that HAL layer uses global/static state . When you instantiate two BNO08x objects, both try to share the same underlying HAL context. This is why multi-sensor setups fail even on I2C with a multiplexer — the second begin() always fails because the HAL is already bound to the first instance .

C. ESP32-S3 silicon bug with multiple SPI slaves

The ESP32-S3 has a documented issue where the first transaction after a CS switch is corrupted when two or more slaves share the same bus . The workaround used by others is to send a “dummy” first transaction after every CS assertion. Since the BNO08x initialization is timing-sensitive (SHTP header exchange), a corrupted first packet causes beginSPI() to timeout at ~30 ms.

2. SPI vs I2C for wearable / dynamic use

Table
InterfaceRecommendationReason
SPIFaster (up to 3 MHz), lower latency, better for high-rate fusion outputs.Preferred if you can solve the bus-contention issue.
I2CSimpler wiring, but BNO086 maxes at 400 kHz and the SparkFun library has the same multi-instance bug on I2C .Only viable with a TCA9548A multiplexer and library patches.
For a dynamic wearable, SPI is technically superior because the BNO086’s rotation-vector reports at high rates will saturate I2C bandwidth if you run two sensors plus other Qwiic devices. However, SPI is only viable here if you isolate the MISO lines or use separate buses.

3. Known hardware quirks with multiple BNO08x devices

  • PS0 = WAKE in SPI mode: The PS0 pin doubles as the active-low WAKE input. If your initialization code (or the library) toggles WAKE at the wrong time, it can accidentally wake the other sensor and put it in an unexpected state
    .
  • H_INTN is mandatory: The SparkFun library requires the INT pin for reliable communication . With two sensors, you must ensure the library does not confuse which INT belongs to which instance (again, the static-HAL problem).
  • Reset sequencing: The BNO08x datasheet specifies that the host must wait for H_INTN assertion after NRST release before starting SHTP communication
    . If both sensors assert INT simultaneously and the library uses a single global interrupt handler, events are missed.

Recommended fixes (in order of effort)

Option 1: Use two separate SPI buses (easiest if pins allow)

The ESP32-S3 has FSPI (SPI2) and HSPI (SPI3) available . Put THIGH on FSPI and SHIN on HSPI with completely independent pin sets. This sidesteps both the silicon bug and the MISO contention issue.
cpp
Copy
SPIClass *spiTHIGH = new SPIClass(FSPI);  // or HSPI
SPIClass *spiSHIN  = new SPIClass(HSPI);  // or FSPI

Option 2: Add tristate buffers on MISO (if you must share one bus)

If you are constrained to one SPI bus, buffer each BNO086’s MISO line with a 74HC125 (or 74LVC1G125 per channel). Tie the buffer’s OE to the respective CS line (inverted). This guarantees the non-selected sensor electrically disconnects from the bus .

Option 3: Workaround for the ESP32-S3 first-transaction bug

If the MISO lines are already isolated and it still fails, insert a dummy read immediately after each digitalWrite(CS, LOW) inside the library’s HAL or your wrapper. The ESP32-S3 bug report confirms that duplicating the first transfer fixes the corruption .

Option 4: Patch the SparkFun library for multi-instance

You will likely need to modify the library so that each BNO08x instance carries its own HAL context rather than relying on CEVA’s global sh2_hal structure. The PJRC forum found that the hal_wait_for_int() call in enableReport() is particularly problematic with multiple instances .

Quick diagnostic test

Before changing hardware, run this test:
  1. Keep THIGH connected and working.
  2. Disconnect only the SHIN MISO (POCI) pin from the shared bus (leave all other SHIN pins connected).
  3. Try initializing SHIN again.
  • If SHIN now initializes successfully, you have MISO contention → add tristate buffers.
  • If it still fails, the issue is library/HAL state or ESP32-S3 timing → use separate SPI buses or patch the library.
Bottom line: SPI is the better choice for your wearable, but do not share one SPI bus with two BNO086s on the ESP32-S3 without either (a) separate FSPI/HSPI buses, or (b) external MISO tristate buffers. The combination of the BNO08x’s SHTP protocol, the SparkFun library’s static HAL, and the ESP32-S3 multi-slave silicon bug makes a single shared bus unreliable.