docs: record CH390 hardware-bound conclusion

2026-04-01 04:30:27 +08:00
parent 1808f9916f
commit 81594c6520
6 changed files with 340 additions and 20 deletions
@@ -510,3 +510,77 @@ CH390 NCR=0xFF RCR=0xFF IMR=0xFF INTCR=0xFF GPR=0xFF ISR=0xFF
 - The architectural decoupling requirement is complete.
 - The runtime stability requirement is complete.
 - CH390 connection is **still failed**, but the reason is now narrowed to a believable low-level bus/device-response problem rather than a software ownership/concurrency problem.
+
+## 2026-04-01 Final Software Boundary Check: Hardware SPI vs Bit-Bang
+
+### Goal
+
+- Decide whether another software-side SPI transaction rewrite is still justified.
+- Use one last high-signal experiment to separate STM32 hardware-SPI issues from board-level CH390 non-response.
+
+### Experiment
+
+- Kept the normal hardware-SPI identity probe in `ch390_runtime_probe_identity()`.
+- Added a temporary bit-bang register read helper in `Drivers/CH390/CH390_Interface.c` that:
+  - disables `SPI1`
+  - reconfigures `PA5/PA7` as GPIO outputs and `PA6` as GPIO input
+  - clocks out register reads in software with explicit `CS/SCK/MOSI/MISO` control
+  - restores the pins back to hardware-SPI mode before returning
+- On hardware-SPI probe failure, startup now prints one additional RTT line with bit-bang reads of:
+  - `VIDL`
+  - `VIDH`
+  - `PIDL`
+  - `PIDH`
+  - `CHIPR`
+
+### Observed RTT Output
+
+```text
+TCP2UART boot
+ETH init: gpio
+ETH init: spi
+ETH init: reset
+ETH init: probe
+CH390 bitbang VIDL=0xFF VIDH=0xFF PIDL=0xFF PIDH=0xFF CHIPR=0xFF
+ETH init: invalid chip id
+CH390 VID=0xFFFF PID=0xFFFF REV=0xFF NSR=0xFF LINK=0
+CH390 NCR=0xFF RCR=0xFF IMR=0xFF INTCR=0xFF GPR=0xFF ISR=0xFF
+```
+
+### Interpretation
+
+- The MCU is alive, RTT is alive, and the firmware reaches the CH390 identity-probe stage normally.
+- The normal hardware-SPI read path still returns all `0xFF`.
+- The independent bit-bang read path also returns all `0xFF` for the same critical identity registers.
+- This is the most important final discriminator collected so far:
+  - if hardware SPI alone were the remaining problem, bit-bang should have had a realistic chance to return valid IDs
+  - because both methods return the same all-`0xFF` result, the remaining fault is much more consistent with CH390-side non-response than with STM32 SPI peripheral behavior
+
+### External Reference Cross-Check
+
+- Public working CH390/DM9051 drivers commonly use `SPI mode 0`, `1-bit command + 7-bit address` framing, and contiguous packet-memory bursts.
+- Those references support further cleanup of packet-memory transaction framing once basic register access works.
+- They do **not** make packet-memory fragmentation a strong explanation for `VID/PID/basic regs = 0xFFFF/0xFF` from the very start.
+- Therefore the remaining software-side suspects are now weaker than the board-level suspects.
+
+### Final Conclusion
+
+- The project has already removed several real software defects and sources of diagnostic noise:
+  - PHY access timeout hole
+  - watchdog-related HardFault
+  - interrupt-masked blocking SPI runtime path
+  - redundant early CH390 reset in `main()`
+  - warning-producing dead code / unused values
+- After those fixes, both hardware-SPI and bit-bang reads still show CH390 register non-response.
+- The most defensible current conclusion is:
+  - **software is no longer the primary blocker**
+  - the remaining fault is more likely in board wiring, chip power/reset state, effective CS selection, MISO drive, signal integrity, or the CH390D device itself
+
+### Recommended Next Step Outside Firmware
+
+- Probe real waveforms on `CS/SCK/MOSI/MISO/RST/INT` during the identity-read transaction.
+- Specifically verify that:
+  - `CS` actually reaches the CH390 pin and stays low for the transaction
+  - `RST` is released high at the chip pin
+  - `MISO` is actively driven by the CH390 instead of floating high
+  - the CH390 supply and reset domain are valid during the read window