# TCP2UART Debug Handoff

## Scope

This log records the debugging work completed so far for:

- UART1 config/debug path on `COM9`
- UART2/UART3 transparent UART paths on `COM8`/`COM7`
- CH390 and lwIP bring-up status

The goal is to preserve the usable conclusions and avoid repeating invalid test paths after context cleanup.

## Final State Summary

### Confirmed working

- HSE clock path is working on the current board/chip/crystal combination.
- ST-Link + RTT debugging works.
- Firmware boots and RTT shows stable startup output.
- UART2 and UART3 TX paths were validated earlier by host-side observation:
  - `COM8` receives UART2 debug output.
  - `COM7` receives UART3 debug output.
- UART1 config path is working in the current cleaned firmware when the host sends commands with a line ending that the parser actually consumes.
- `AT+?` over UART1 was successfully validated when sent with `\n`.

### Confirmed not yet working

- CH390 is still not operating normally.
- Current one-shot RTT report still shows abnormal values:
  - `CH390 VID=0x3A3A PID=0xCCCC REV=0x00 NSR=0x00 LINK=0`
- Therefore lwIP / Ethernet / TCP end-to-end validation remains blocked by CH390 low-level failure.

## Most Important Lessons Learned

### 1. UART1 config failures were partly test-method failures

Several earlier negative conclusions about UART1 config were caused by the debug method rather than firmware defects.

Examples:

- Sending `AT+?` without the line ending expected by the current parser caused false negatives.
- Frequent open/close cycles on the serial port changed timing and control-line behavior.
- Breakpoints in RX callback / parser code prevented reply transmission and created false "no response" results.
- Heavy RTT logging inside hot UART paths distorted timing and even corrupted RTT control state once.

### 2. UART1 parser expects terminators

`config_uart_rx_byte()` only dispatches a command when it sees `\r` or `\n`.

Successful command form that was confirmed:

```text
AT+?\n
```

Do not assume `AT+?` without line ending is valid for this firmware.

### 3. Cleaned firmware state is preferable for future work

Temporary UART diagnostics were removed again after debugging:

- removed boot markers like `BOOT_UARTx_OK`
- removed periodic UART spam
- removed UART1 byte echo
- removed temporary `config_diag` counters

Useful RTT remains:

- `TCP2UART boot`
- HSE fallback warning if used
- CH390 one-shot status report

## Relevant Code Changes Left In Place

These are intentional and should remain unless there is a specific reason to change them.

### UART1 config path

- `App/config.c`
  - config handle is back on `huart1`
  - `config_uart_rx_byte()` assembles frames from UART1 bytes
  - `config_poll()` dispatches a pending complete frame to `config_try_process_frame()`
  - `config_try_process_frame()` calls `config_process_at_cmd()` and transmits the response on UART1

- `Core/Src/stm32f1xx_it.c`
  - `HAL_UART_RxCpltCallback()` for `huart1` feeds the received byte into `config_uart_rx_byte()` and rearms `HAL_UART_Receive_IT()`

### RTT boot diagnostics

- `Core/Src/main.c`
  - retains RTT boot banner
  - retains one-shot CH390 report
  - no temporary UART spam remains

## Current Firmware Behavior Worth Remembering

### UART1

- UART1 is used for config/debug interaction.
- UART1 parser is line-oriented.
- Use a terminal that sends `LF` or `CRLF` explicitly.

### UART2 / UART3

- UART2 and UART3 are for bridge channels, not the config path.
- Earlier mapping observed during testing:
  - `COM8` aligned with UART2 TX activity
  - `COM7` aligned with UART3 TX activity

### CH390

- Still unresolved at the low level.
- Do not spend time on lwIP / TCP behavior until CH390 register reads look sane.

## Recommended Next Debug Order

### Priority 1: Preserve UART1 config as known-good

Before touching UART1 code again:

1. Open `COM9` at `115200 8N1`
2. Send:

```text
AT+?\n
```

3. Confirm a full config dump is returned.

If this fails again, check the terminal's actual line ending first before changing code.

### Priority 2: Re-verify UART2/UART3 only if needed

If bridge debugging resumes, first confirm the host can actually open `COM7` and `COM8`.
Host-side availability was inconsistent during the previous session and caused false negatives.

### Priority 3: Resume CH390 low-level debugging

This is the real remaining blocker.

Suggested next steps:

1. Focus on SPI-level sanity before lwIP.
2. Re-check CH390 reset / CS / SPI timing and electrical path.
3. Verify whether SPI mode is correct for the actual hardware.
4. Confirm register reads from CH390 return plausible values before attempting link/TCP tests.

## What Not To Repeat

- Do not judge UART1 config by sending commands without a terminator.
- Do not leave breakpoints inside UART RX callback or parser while expecting normal replies.
- Do not flood RTT inside hot UART receive paths.
- Do not conclude lwIP is broken before CH390 identity reads are sane.
- Do not trust `Win32_SerialPort` alone for COM availability; sometimes `mode COMx` / `Get-PnpDevice -Class Ports` gives a different picture.

## Known Useful Commands

### UART1 config test

```text
AT+?\n
```

### Optional follow-ups

```text
AT+BAUD1=115200\n
AT+SAVE\n
AT+RESET\n
```

## One-Line Handoff

UART1 config is working when tested correctly with a terminator; CH390 is still the unresolved core issue and should be the next serious debug target.