<div dir="ltr">Hi All,<div><br></div><div>I'm running an EPICS ioc server (EPICS 7.0.10)  with RTEMS 6.2 on a Raspberry Pi 3B+ with rtems-libbsd  (6-freebsd-14) and<br>encountering a reproducible system hang after several minutes of operation.<br>Through systematic elimination testing I've narrowed the root cause to the<br>DWC OTG USB controller driver. I'd appreciate any recommendations on how<br>to address this. I can of course use the EPICS ioc server under linux on RPi but just tried to have the RTEMS - Hard real time system which is much more deterministic.</div><div>The boot time for the RPi with EPICS/RTEMS is around 7 sec which is extremely fast!</div><div><br>Environment<br>-----------<br>- Board: Raspberry Pi 3B+ (BCM2837, boardrev a020d3)<br>- RTEMS: rtems-6.2 (ARM/ARMv4/raspberrypi2)<br>- Network stack: rtems-libbsd (RTEMS_BSD_CONFIG_BSP_CONFIG + RTEMS_BSD_CONFIG_INIT)<br>- Ethernet: LAN7515 USB Ethernet (muge driver, via DWC OTG)<br>- Application: EPICS IOC (but hang occurs with minimal/empty IOC as well)<br>- Console: UART serial (/dev/ttyS0)<br><br>Symptom<br>-------<br>The system boots and runs normally, then the entire system freezes —<br>including the UART serial console (which is not USB-dependent). No crash<br>message, no stack dump — a hard hang requiring power cycle.<br><br>The time-to-hang depends on the system tick rate:<br>- CONFIGURE_MICROSECONDS_PER_TICK=500  (2 kHz): hangs after ~2 minutes<br>- CONFIGURE_MICROSECONDS_PER_TICK=10000 (100 Hz): hangs after ~5-6 minutes<br><br>During the hang, the UART becomes completely unresponsive, suggesting a<br>kernel-level deadlock or interrupt handler issue rather than an<br>application-level problem.<br><br>Elimination testing performed<br>-----------------------------<br>I systematically disabled components to isolate the cause. All tests below<br>used CONFIGURE_MICROSECONDS_PER_TICK=10000 (100 Hz):<br><br>1. Disabled all EPICS database records (no record processing) -> still hangs<br>2. Disabled periodic NTP sync (no socket operations) -> still hangs<br>3. Disabled IP configuration (no ifconfig, no route, no network traffic,<br>   but USB/DWC OTG still initialised via RTEMS_BSD_CONFIG_BSP_CONFIG)<br>   -> still hangs (~5-6 min), USB hub enumeration continues in background:<br>      ugen1.2: <vendor 0x0424 product 0x2514> at usbus1<br>      uhub1 on uhub0<br>      ...<br>   Console output is garbled by concurrent USB enumeration messages,<br>   suggesting interrupt contention.<br>4. Commented out RTEMS_BSD_CONFIG_BSP_CONFIG and the<br>   #include <bsp/nexus-devices.h> to prevent DWC OTG initialisation<br>   -> STABLE, ran for 14+ minutes with no hang (test stopped manually)<br><br>The libbsd software stack (loopback, sockets, telnetd) continues to<br>function in test 4 — only the hardware BSP devices (DWC OTG, muge,<br>uhub, ukphy) are excluded.<br><br>Minimal reproduction<br>--------------------<br>Build an RTEMS 6.2 application for raspberrypi2 BSP with:<br><br>  #define RTEMS_BSD_CONFIG_BSP_CONFIG<br>  #define RTEMS_BSD_CONFIG_INIT<br>  #include <machine/rtems-bsd-config.h><br>  #include <bsp/nexus-devices.h>     /* in one translation unit */<br><br>  #define CONFIGURE_MICROSECONDS_PER_TICK 10000<br><br>The application does not need to configure any network interface or<br>perform any USB transfers — the DWC OTG hub polling alone triggers<br>the hang after ~5-6 minutes.<br><br>Commenting out RTEMS_BSD_CONFIG_BSP_CONFIG and the nexus-devices.h<br>include eliminates the hang.<br><br>Boot log (abbreviated, from hanging configuration)<br>--------------------------------------------------<br>RTEMS RPi 3B+ 1.3 (1GB) [00a020d3]<br>nexus0: <RTEMS Nexus device><br>dwcotg0: <DWC OTG 2.0 integrated USB controller> on nexus0<br>usbus1 on dwcotg0<br>usbus1: 480Mbps High Speed USB v2.0<br>ugen1.1: <DWCOTG OTG Root HUB> at usbus1<br>uhub0 on usbus1<br>uhub0: <DWCOTG OTG Root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus1<br>uhub0: 1 port with 1 removable, self powered<br>ugen1.2: <vendor 0x0424 product 0x2514> at usbus1<br>uhub1 on uhub0<br>uhub1: <vendor 0x0424 product 0x2514, class 9/0, rev 2.00/b.b3, addr 2> on usbus1<br>uhub1: 4 ports with 3 removable, self powered<br>ugen1.3: <vendor 0x0424 product 0x2514> at usbus1<br>uhub2 on uhub1<br>uhub2: <vendor 0x0424 product 0x2514, class 9/0, rev 2.00/b.b3, addr 3> on usbus1<br>uhub2: 3 ports with 2 removable, self powered<br>ugen1.4: <vendor 0x0424 product 0x7800> at usbus1<br>muge0: <vendor 0x0424 product 0x7800, rev 2.10/3.00, addr 4> on usbus1<br>muge0: Chip ID 0x7800 rev 0002<br>miibus0: <MII bus> on muge0<br>ukphy0: <Generic IEEE 802.3u media interface> PHY 1 on miibus0<br>info: ue0: <USB Ethernet> on muge0<br>[system hangs after ~5-6 minutes, UART unresponsive]<br><br>Questions<br>---------<br>1. Is this a known issue with the DWC OTG driver on RPi 3B+?<br>2. Are there any configuration options (hub polling interval, interrupt<br>   coalescing, DMA settings) that might work around the problem?<br>3. Would a newer version of rtems-libbsd contain fixes for this?<br>4. Is there an alternative Ethernet driver approach for RPi 3B+ that<br>   avoids the DWC OTG USB path?</div><div>5. Is there any known project which uses RPi with RTEMS?</div><div>(it looks like that the option to run RTEMS on RPi4 or RPi 5 can not be considered since the BSP in RTEMS kernel  is not yet finalised.<br>The RPi4 or RPi 5 would be much better candidates vs RPi 3 B+ since they use direct connection to Ethernet instead of the USB-Ethernet) <br><br>Thank you for any guidance.<br><br>Mirek<br><br><br></div></div>