Problem2: in song mode UI shows 6m(Am) but MIDI played AM7
(E2 A2 E3 G#3 C#4 E4). Root cause: BL_Set_led wrote the LED frame's
chord code into chord_type_index_map of the group middle key
(LED_L6 -> key17), so a guidance frame carrying 0x02 (M7) turned the
Am key into AM7. Remapping on the chord page only helped until the
next LED frame.
- BL_Set_led: light LED only, drop all chord_type_index_map writes;
chord quality is owned by map page 02 03/02 04 (BT_Chord_offset_map)
- handleReadRhythmMap / Return_Light_buff: fix type->protocol read-back
encoding (m7->0x0A, M7->0x02, ad9->0x04, m7-5->0x0B, sus2->0x1F,
sus4->0x1E), re-landing the 0917 verified fix
- BT_Chord_offset_map: accept dominant-7 doc code 0x0D (legacy 0x13 kept)
- tests: test_chord_map_fix.py (16/16 PASS on device),
test_fret_positions.py, test_problem2_song_am.py (7/7 PASS:
post-LED strum stays E2 A2 E3 A3 C4 E4)
Co-authored-by: Cursor <cursoragent@cursor.com>
App writes for timbre/BPM/transpose/style were refreshing LCD and
reloading tone packs on the 768B BLE recv stack, causing overflow and
crashes. Route heavy work through MSG_ID_BLE_* into the UI task, and
notify App when the device changes rhythm style.
Co-authored-by: Cursor <cursoragent@cursor.com>
Enlarge BT recv stack, move large handlers/log buffers off the stack, clamp key indexes, and yield in W25Q busy-wait so BLE protocol tests stay stable.
Co-authored-by: Cursor <cursoragent@cursor.com>
Point system-settings rows at the correct Flash icons, keep Main/UI alive across soft-off, and expose git build id for 01 0C with matching BLE tests.
Co-authored-by: Cursor <cursoragent@cursor.com>
Encode 01 07 UID as hex ASCII and use 01 0F (keep 01 FF alias) so high-bit bytes are not dropped as timestamps.
Co-authored-by: Cursor <cursoragent@cursor.com>
TaskBTRecvThread previously started only after mode select, so GATT SysEx never reached the parser until then; verified BLE-MIDI 01 01 now replies with GATT notify.
Co-authored-by: Cursor <cursoragent@cursor.com>
yuquanjun