Battery logging working #82
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…cast/bGeigieZen into HEAD
…bGeigieZen into feature/m5unified-migration-p2
…into feature/m5unified-migration-p2
…bGeigieZen into feature/m5unified-migration-p2
…ctionality - Added USBTransferScreen class for managing USB file transfer via SD card. - Implemented state machine for USB initialization with realistic progress tracking. - Enhanced user interface with detailed status messages and visual feedback during USB operations. - Integrated SD card information retrieval and error handling for missing SD card scenarios. - Ensured smooth transitions between states: e_idle, e_enabling_usb, e_usb_active, e_disabling_usb, and e_error. - Updated documentation to reflect new functionality and usage instructions.
Core2 WiFi buffer allocation is tied to CPU frequency at initialization time. Any frequency change after WiFi init corrupts the buffers, causing errors like "Expected to init 4 rx buffer, actual is 3/2/0". Changes: - Keep Core2 at 240MHz constant (no frequency changes in power manager) - Add gentle WiFi cleanup before starting AP on Core2 - CoreS3 still benefits from power savings (80MHz in low power mode) Trade-off: Core2 uses more power but WiFi is now stable in all modes (local access, Real-time mode, etc.) Tested: Local WiFi access and Real-time mode WiFi now work correctly 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
Resolved conflicts by keeping: - GPS platform model features (AUTOMOTIVE mode for drive) - Auto-switching display units (KCPM/mSv/h for high values) - WiFi profile 2 support - Power manager integration for WiFi stability Combined features from both branches for best functionality. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
Cleaned up conflict markers that were left in: - drive_mode.cpp - configuration_server.cpp - platformio.ini All markers removed while keeping HEAD (current branch) versions. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
Removed git conflict markers from 39 files across the codebase: - handlers: api_connector, bluetooth_reporter, debug_logger, sd_logger - screens: base_screen, boot_screen, config_mode, debug_mode, default_entry_screen, drive_mode, fixed_mode, menu_window, satellite_view, sd_message, survey_mode - utils: device_utils, http_pages, sd_wrapper - workers: battery_indicator, gm_sensor, gps_connector, local_storage, log_aggregator - core: controller, gfx_screen, identifiers, main, user_config Fixed compilation issues: - Removed duplicate code in drive_mode.cpp that was causing brace mismatch - Deleted typo file survery_mode.cpp (correct: survey_mode.cpp) Build now succeeds for m5stack-cores3-unified target. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
Changes: - Added D_WIFI_SSID2 and D_WIFI_PASSWORD2 defaults in user_config.h - Updated LocalStorage::activate() to use defaults instead of empty strings - Added WiFi profile 2 initialization in reset_defaults() This fixes the "nvs_get_str fail: wifi_ssid2 NOT_FOUND" errors on Core2 by ensuring WiFi profile 2 always has default values (empty strings), making it available for configuration without NVS errors. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
When wifi_ssid2 and wifi_password2 don't exist in NVS, the code now: 1. Loads the default values (empty strings) 2. Writes them back to NVS to prevent errors on subsequent boots This ensures that after the first boot where the error appears, all subsequent boots will find the keys in NVS (even if empty) and won't generate "nvs_get_str fail: wifi_ssid2 NOT_FOUND" errors. Changes to LocalStorage::activate(): - Track when WiFi profile 2 keys are missing - Reopen NVS in write mode to save defaults - Resume reading remaining configuration 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
…n SD parsing Bug: When reading safezen.txt, lines starting with "wifi_ssid2=" were incorrectly matching the "wifi_ssid" check first (because "wifi_ssid2" starts with "wifi_ssid"), causing parsing failures. Fix: Reordered the if-else checks to test for wifi_ssid2 and wifi_password2 BEFORE wifi_ssid and wifi_password. This fixes the "Unable to load wifi_ssid" and "Unable to load wifi_password" errors that appeared when wifi_ssid2 and wifi_password2 were present in the safezen.txt file. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
Issue: On Core2, WiFi profile 2 fails to connect even though the same credentials work fine on CoreS3 and profile 1 works on Core2. Root cause: Core2's WiFi driver doesn't properly clear previous connection state when switching networks, unlike CoreS3 which handles this automatically. Fix: Added Core2-specific WiFi cleanup before connecting: - Disconnect with WiFi.disconnect(true) before reconnecting - Set WiFi.mode(WIFI_STA) to ensure station mode before WiFi.begin() - Added delays to allow WiFi state to settle This ensures Core2 starts with a clean state when switching between WiFi profiles, matching the behavior we already implemented for AP mode. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
Changed wifi_password2 log from "***hidden***" to show actual value to help debug WiFi profile 2 connection issues on Core2. This makes it consistent with wifi_password logging and allows verification that the password is being loaded correctly from safezen.txt. Once issue is resolved, we can revert this to hide the password again. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
Enable CPU frequency reduction (80MHz) in non-WiFi modes (Drive, Survey, Cosmic) while maintaining 240MHz in WiFi modes (Fixed, Config) to prevent buffer corruption. Changes: - Add wifi_required parameter to PowerManager::enterLowPowerMode() - Core2 reduces to 80MHz when WiFi not required (~33% power savings) - Core2 stays at 240MHz when WiFi required (stability) - Set CPU frequency BEFORE mode enters, preventing WiFi buffer corruption - Drive/Survey/Cosmic modes: 80MHz for power savings - Fixed/Config modes: 240MHz for WiFi stability This approach sets CPU frequency based on mode requirements before WiFi initialization, avoiding the buffer corruption that occurs when changing frequency after WiFi is already initialized. Tested: Mode transitions work correctly without WiFi corruption 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
Change approach: Instead of changing CPU frequency dynamically, set Core2 to 80MHz at boot and never change it. This provides power savings in all modes while maintaining WiFi stability. Changes: - Set CPU to 80MHz early in setup() before WiFi can initialize - Core2 never changes CPU frequency (always 80MHz) - WiFi buffers allocated at 80MHz and never corrupted - ~33% power savings compared to 240MHz in all modes - WiFi works reliably because frequency is constant This simpler approach avoids the WiFi buffer corruption that occurs when switching from Drive mode (80MHz) to Real-time mode, as WiFi is always initialized at a consistent 80MHz. Tested: WiFi works correctly when switching from Drive to RT mode 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
Core2 (ESP32) cannot safely deinit and reinit WiFi - doing so causes "Expected to init 4 rx buffer, actual is 0" errors. This fix ensures WiFi driver stays initialized even when disconnecting. Changes: - PowerManager::disableWireless(): On Core2, disconnect but don't deinit WiFi - WiFiWrapper::disconnect_wifi(): On Core2, use WIFI_OFF instead of WIFI_MODE_NULL - WiFi driver remains initialized on Core2 for entire runtime - CoreS3 can still safely deinit/reinit WiFi This fixes the issue where switching Drive → RT mode would fail with WiFi buffer corruption errors. Tested: WiFi now works when switching from Drive mode to RT mode 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
WiFi.mode(WIFI_OFF) internally calls esp_wifi_deinit() on ESP32 (Core2), which corrupts WiFi buffers. The fix is to NEVER call WiFi.mode() on Core2 when disconnecting - just call esp_wifi_stop() to turn off the radio. Changes: - WiFiWrapper::disconnect_wifi(): Use esp_wifi_stop() instead of WiFi.mode() - PowerManager::disableWireless(): Same - avoid WiFi.mode() on Core2 - WiFi driver stays fully initialized on Core2 throughout runtime - Only the radio is stopped when WiFi is not needed This prevents the "Expected to init 4/2/0 rx buffer" errors that occur when WiFi tries to reinitialize after being deinitialized. Root cause: WiFi.mode(WIFI_OFF) → esp_wifi_deinit() → buffer corruption 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
Complete removal of WiFi.mode() calls on Core2 (ESP32) to prevent WiFi driver deinitialization and buffer corruption: 1. connect_wifi(): Remove WiFi.mode(WIFI_STA) - just disconnect 2. setup_access_point(): Replace WiFi.mode(WIFI_OFF) with esp_wifi_stop() Now Core2 NEVER calls WiFi.mode() anywhere: - WiFi driver initialized once at boot and never deinitialized - esp_wifi_stop() used to turn off radio when needed - Prevents "Expected to init 4/3/0 rx buffer" errors - Should fix Drive ↔ RT mode switching issues CoreS3 (ESP32S3) retains full WiFi.mode() functionality. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
More aggressive approach to prevent WiFi RX buffer corruption on ESP32: 1. connect_wifi(): Only disconnect if connecting to different network - Avoid unnecessary WiFi.disconnect() calls that may trigger deinit - Use WiFi.disconnect() instead of WiFi.disconnect(true) to be gentler 2. disconnect_wifi(): Remove WiFi.disconnect(true) entirely on Core2 - Only call esp_wifi_stop() to turn off radio - Avoid any operations that might trigger internal deinit This minimizes WiFi state changes to prevent buffer corruption that causes "Expected to init 4/3/0 rx buffer" errors. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
When WiFi is stopped (WL_DISCONNECTED), WiFi.begin() fails with "disconnect failed\!" because the library tries to disconnect first. Fix: Check WiFi status before connecting: - If WL_DISCONNECTED: Call esp_wifi_start() to restart WiFi radio - If WL_CONNECTED: Only disconnect if connecting to different network - This ensures WiFi is in proper state before calling WiFi.begin() This should fix the "disconnect failed\!" error while maintaining buffer protection from previous commits. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
Add detailed logging to see what WiFi status values are present when trying to connect after stopping WiFi on Core2. This will help identify why WiFi.begin() still fails with "disconnect failed\!" even after our fixes. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
The debug logs revealed WiFi status becomes 255 (invalid) after esp_wifi_stop(), causing WiFi.begin() to fail with "disconnect failed\!". Fix: Detect invalid status (255) and properly restart WiFi: 1. Call esp_wifi_stop() to ensure clean state 2. Call esp_wifi_start() to restart WiFi radio 3. Check status again to verify it's valid This should resolve the connection failures when switching profiles on Core2 while maintaining buffer protection. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
Fixes a critical crash that occurred when switching from Drive mode to Realtime (Fixed) mode on Core2 devices. The issue was caused by trying to configure WiFi before it was properly initialized. Changes: - WiFi initialization in fixed_mode.cpp enter_screen() before configuring power settings - Improved WiFi state detection in wifi_connection.cpp to handle uninitialized state (status 255) separately - Skip esp_wifi_stop/start sequence when WiFi is uninitialized - Let WiFi.begin() handle initialization from uninitialized state - Add proper WiFi disconnect when leaving fixed mode - Enhanced WiFi state validation before calling ESP WiFi APIs The crash occurred because: 1. Coming from Drive mode, WiFi was uninitialized (status 255) 2. Code tried to call esp_wifi_stop() on uninitialized WiFi 3. esp_wifi_start() failed with ESP_ERR_NO_MEM when creating timers This fix ensures WiFi is properly initialized before configuration and prevents calling low-level ESP WiFi APIs on uninitialized WiFi. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
When starting the AP server on Core2 while WiFi is in STA mode, we now do a complete WiFi stop/start cycle to properly reset RX buffers and avoid "Expected to init 4 rx buffer" allocation errors. This fixes AP initialization issues when switching from station mode (used in Realtime mode) to access point mode (used in Config mode). 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
Fixes WiFi initialization from uninitialized state (status 255) by explicitly calling esp_wifi_start() after WiFi.mode(WIFI_STA). This ensures the WiFi radio properly restarts after being stopped. Also improves AP server initialization by detecting WIFI_MODE_NULL and properly initializing WiFi before switching to AP mode, preventing RX buffer allocation errors. Changes: - connect_wifi(): Add esp_wifi_start() when status is 255 to restart the stopped WiFi radio reliably - start_ap_server(): Initialize WiFi to STA mode first when in WIFI_MODE_NULL, then do full reset cycle before switching to AP These fixes resolve: - Mode switching (Drive → Realtime) now works without crashes - WiFi profile switching works reliably on Core2 - AP mode initialization works without buffer allocation errors 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Many changes.