refactor: 清理UART调试代码并保留RTT诊断
This commit is contained in:
@@ -0,0 +1,174 @@
|
||||
# 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.
|
||||
Reference in New Issue
Block a user