MikeFaith/xblink
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Add LP5562EVM USB-I2C control tool, document reverse-engineered protocol

Browse Source 
Reverse-engineered the MSP430 serial protocol on the LP5562EVM:
- I<addr><reg> reads, O<addr><reg><data> writes, status 00=OK / 02=NAK
- EN pin must be jumpered to VDD (MSP430 doesn't drive it after reset)
- CONFIG (0x0B) is write-only, W_CURRENT (0x09) not writable via bridge
- LED cycling verified: all 4 channels respond to direct PWM control

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
michael
2026-03-05 11:11:35 -08:00
parent 90eab7990c
commit 5970a21b54
3 changed files with 374 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
docs/STATUS.md
View File

@@ -1,7 +1,7 @@
# xblink Project Status
**Current Milestone**: M1 — LED Smoke Test (code ready, needs USB cable to flash)
**Last Updated**: 2026-03-03
**Current Milestone**: M1 — LED Smoke Test (I2C verified via EVM USB bridge, XIAO M0 flash pending)
**Last Updated**: 2026-03-05
---
@@ -23,7 +23,8 @@
- [x] Create `src/led/mod.rs` with re-exports
- [x] Update `main.rs` with I2C init + GPIO EN + LP5562 direct PWM test
- [x] Verify `cargo build --release` compiles
- [ ] Flash and verify RGBW LED channels on LP5562EVM
- [x] Verify LP5562 I2C control via EVM USB-to-I2C bridge (`tools/lp5562_evm.py`)
- [ ] Flash XIAO M0 and verify RGBW LED channels with Rust firmware
### M2: Engine Patterns

90
docs/plans/2026-03-05-lp5562evm-protocol.md Normal file
View File

@@ -0,0 +1,90 @@
# LP5562EVM MSP430 Serial Protocol (Reverse-Engineered)
**Date**: 2026-03-05
**Status**: Working — I2C read/write verified, LEDs cycling
## Hardware
- **EVM**: LP5562EVM (SNVU203A) with MSP430F5510 USB-to-I2C bridge
- **USB**: CDC device, VID:PID `2047:0300`, appears as `/dev/ttyACM0`
- **Baud**: 115200, 8N1
- **EN pin**: Must be jumpered to VDD externally — MSP430 does NOT drive EN after reset
## Protocol
Commands are ASCII text, no line terminator needed. The MSP430 parses character-by-character and responds after receiving the expected number of hex digits.
### Commands
| Command | Format | Response | Description |
|---------|--------|----------|-------------|
| `?` | `?` | `TI Sep 12 2012 08:19:25\n` | Firmware version |
| `I` (read) | `I<addr2><reg2>` | `SS DD OK\n` | I2C register read |
| `O` (write) | `O<addr2><reg2><data2>` | `SS OK\n` | I2C register write |
| `R` (read) | `R<addr2><reg2>` | `OK\n` | I2C read (no data returned) |
| `A` | `A` | `OK\n` | Unknown (possibly internal) |
- `addr2`: 2-char hex I2C 7-bit address (e.g., `30` for LP5562)
- `reg2`: 2-char hex register address
- `data2`: 2-char hex data byte
- `SS`: 2-char hex status (`00` = success, `02` = I2C NAK / device not responding)
- `DD`: 2-char hex data byte read from device
### Other Command Prefixes
These accept input but are not fully understood:
| Prefix | Chars consumed | Response | Guess |
|--------|---------------|----------|-------|
| `S` | 2 hex chars | (silent) | GPIO/setting control? |
| `V` | 2 hex chars | (silent) | Voltage/value setting? |
| `C` | 6 hex chars | `OK\n` | Config/control? |
| `P` | 8 hex chars | (silent or `OK`) | Program memory? |
### Invalid Commands
Single characters not recognized as command prefixes return `?\n`. Extra characters after a complete command also return `?\n` each.
## LP5562 Register Quirks via EVM Bridge
| Register | Address | Writable | Read-back | Notes |
|----------|---------|----------|-----------|-------|
| ENABLE | 0x00 | Yes | Yes | |
| OP_MODE | 0x01 | Yes | Yes | |
| B/G/R/W_PWM | 0x02-0x05 | Yes | Yes | |
| B/G/R_CURRENT | 0x06-0x08 | Yes | Yes | |
| W_CURRENT | 0x09 | No | Always 0x00 | Write ACKs but no effect |
| CONFIG | 0x0B | Functional | Always 0x00 | Write-only: takes effect but reads 0 |
| STATUS | 0x0C | N/A | Yes | Read-only |
| LED_MAP | 0x70 | Yes | Yes | Default 0x39 (engines mapped) — must set to 0x00 for direct PWM |
## Working Init Sequence
```
O300DFF # Reset (write 0xFF to RESET register)
# Wait 500ms
O300040 # ENABLE = 0x40 (chip_en)
# Wait 1ms (>500us startup)
O300B01 # CONFIG = 0x01 (internal oscillator) — write-only
O307000 # LED_MAP = 0x00 (all channels = I2C direct)
O300632 # B_CURRENT = 0x32 (5mA)
O300732 # G_CURRENT = 0x32
O300832 # R_CURRENT = 0x32
# W_CURRENT left at default 0xAF (0x09 not writable)
O3002FF # B_PWM = 0xFF (full brightness)
```
## LED Hardware on EVM
- **D1**: LRTB_G6SF (Osram RGB LED) — driven by B/G/R channels
- **D2-D5**: LW Q38E (Osram white LEDs) — driven by W channel
- **D7**: LSL296 (red status LED) — driven by MSP430, not LP5562
- All LP5562 LED outputs pass through **P5** header (4x2 dual-row with jumpers)
## Key Discovery: EN Pin
The LP5562 EN pin is controlled by the MSP430's GPIO (EN-UC), connected through the P6 header. After USB reset, the MSP430 holds EN low. The TI Windows GUI software presumably sends a command to assert EN, but we were unable to identify which serial command does this.
**Workaround**: Jumper EN directly to VDD (3.3V) on P1 or P6 header. This is acceptable because in the final xblink design, EN is controlled by a wired-AND circuit (MCU GPIO + hall sensor), not the EVM's MSP430.
Without EN high, all I2C reads return status `02` (NAK) with data `00`.