HIL: ch32v307v_r1_1v0-usbhs net_lwip_webserver HTTP connect times out #4477

Activity

1. hathach

   added

   follow-upDeferred work from a PR or investigationDeferred work from a PR or investigation

   on Nov 10, 2026
2. github-actions

   added

   Prio 📌

   on Nov 10, 2026
3. HiFiPhile

   added a commit that references this issue on Nov 11, 2026

   wch/usbhs: report resume when the SUSPEND interrupt fires on bus resume

   ...

   00af84b
4. HiFiPhile commented on Nov 12, 2026

   

   HiFiPhile

   on Nov 12, 2026

   Collaborator

   More actions

   I tried to reproduce this away from ci.lan. Nothing outside it fails, so the cause is probably the CI board or the rig.

   #4493 fixes a different bug

   • What it fixes: I first reproduced the symptom on a Windows 10 host with a nanoch32v305, which uses the same CH32V30x USBHS controller and dcd_ch32_usbhs.c. That failure was a real driver bug: the SUSPEND interrupt fires on both suspend and resume, and the DCD reported both as suspend. After one host suspend, tud_ready() stayed false, and the example dropped every outgoing frame. wch/usbhs: report resume when the SUSPEND interrupt fires on bus resume #4493 fixes it.
   • It doesn't fix this issue: in wch/usbhs: report resume when the SUSPEND interrupt fires on bus resume #4493's own HIL run, ch32v307v_r1_1v0-usbhs still fails net_lwip_webserver the same way. Its other cells pass, including usbtest 30/30.

   Linux host: the V305 passes

   I ran the same V305 on the tusb rig with Linux cdc_ncm, the interface in its own netns at 192.168.7.2 as net_test.py sets it up. Ping works, and HTTP returns all 7425 B of the asset set over 3 rounds. That holds with and without #4493. Linux never suspended the device while the interface was open (runtime_suspended_time=0), so the suspend bug can't be the cause on ci.lan either.

   DMA address range: probably not the cause

   ch32v307v_r1_1v0 links with 64K RAM and nanoch32v305 with 32K. I compared the two net_lwip_webserver builds (MinSizeRel), and every buffer USBHS DMA uses sits at the same address on both:

   symbol	address
   ncm_epbuf (NTB OUT/IN and notification)	0x20004c90 (0x1810 B)
   ep0_buffer	0x20006568
   end of .bss	0x20006860

   Only _estack moves (0x20010000 vs 0x20008000). No USB transfer comes from the stack: NCM uses only ncm_epbuf and NULL for ZLPs, and EP0 always copies through ep0_buffer. So a DMA range limit above 32K wouldn't touch this example. These are local builds. I couldn't get the CI artifact, because the API returned 502.

   What's left

   What differs from my setup:

   • the CH32V307 board itself (clock, PHY, option-byte RAM split);
   • the ci.lan host and hub (19-1.7);
   • usb1 naming: the failing interface stays usb1, while the passing usbfs one is renamed to enx…. Possibly only timing.

   With a hold on the ci.lan board, the next checks are:

   1. tcpdump -i usb1 in the namespace during check_http: does an ARP reply ever come back?
   2. usbmon on the bulk endpoints: do OUT NTBs get ACKed, and does any IN NTB return?
   3. On the target over WCH-Link with gdb: _usbd_dev.suspended, ncm_interface.xmit_sequence and lwip_stats. These separate "OUT never reaches lwIP" from "IN never leaves the device".
5. HiFiPhile

   added a commit that references this issue on Nov 12, 2026

   TEST ONLY: build ch32v307v_r1_1v0 like nanoch32v305 (to be dropped)

   ...

   f349053