TCP2UART/.debug/uart-ch390-debug-handoff.md

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:

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:

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

AT+?\n

Optional follow-ups

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.