-
Notifications
You must be signed in to change notification settings - Fork 20
fix(bmi270): make burst write size configurable #566
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
✅Static analysis result - no issues found! ✅ |
finger563
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the improvement! I've got a minor suggestion to ensure no change in behavior for existing users but once that's changed it looks good!
8db49be to
67eb33a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
This PR adds a configurable burst_write_size parameter to address stack overflow issues on memory-constrained devices (e.g., ESP32-C3) during BMI270 sensor initialization. The configuration file upload previously used the full 8192-byte size for burst writes, which could exceed stack limits on certain platforms.
Key Changes:
- Added
burst_write_sizefield toBmi270::Configstruct with default value of 0 (which defaults to full config file size for backward compatibility) - Modified constructor to initialize
burst_write_size_member based on config value - Updated
load_config_file()to use configurable burst size instead of hardcoded full file size
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Description
Motivation and Context
On devices with limited stack size (such as the ESP32-C3), the default burst write operation during the BMI270 initialization can cause a Stack Protection Fault (Panic).
How has this been tested?
I tested this on an ESP32-C3 where the initialization was previously failing with a stack panic.
Screenshots (if appropriate, e.g. schematic, board, console logs, lab pictures):
Detected in task "main" at 0x4201ab88
--- 0x4201ab88: espp::BasePeripheral<unsigned char, true, true, true>::write_many_to_register(unsigned char, unsigned char const*, unsigned int, std::error_code&) at /PATH/managed_components/espp__base_peripheral/include/base_peripheral.hpp:606
Stack pointer: 0x3fc92430
Stack bounds: 0x3fc93a08 - 0x3fc94a00
Types of changes
Checklist:
Software
.github/workflows/build.ymlfile to add my new test to the automated cloud build github action.Hardware