Forum Discussion
Cyclone 10 GX Nios V Ethernet Ping Issue - UC/TCP-IP Error 20012 and TSE/mSGDMA Debugging ;
Hello ,
I am developing Ethernet communication on a Cyclone 10 GX FPGA using Nios V/m, the Triple-Speed Ethernet (TSE) IP, msgDMA, a Marvell Alaska 88E1111 PHY, UC-OS-II, and the recommended UC-TCP-IP software components. I am using the recommended UC/TCP-IP .c and .h source files, but I am facing an initialization error before I can complete ping testing.
Hardware/software configuration: FPGA: Cyclone 10 GX, Processor: Nios V/m at 50 MHz, Quartus Prime Pro: 26.1.0, Ethernet: TSE with TX/RX mSGDMA, PHY: Marvell Alaska 88E1111 over SGMII, Network stack: UC/TCP-IP, RTOS: UC/OS-II, Board IP: 10.0.0.2/24, PC-to-board ping: Not working
Current initialization error
The network initialization fails at: NetSock_Init(&err); The returned error is: NET_SOCK_ERR_INIT_CONN_REQ_FAULT (20012)
I am using the recommended MicroC/TCP-IP source files with MicroC/OS-II. Before calling NetSock_Init(&err), the following initialization functions execute successfully:
Net_InitDflt(); NetCtr_Init(); NetStat_Init(); Net_KAL_Init(); NetTmr_Init(); NetBuf_Init(); NetConn_Init(); NetMgr_Init(&err); NetICMP_Init(&err); NetIP_Init(&err); NetIGMP_Init(); NetUDP_Init(); NetTCP_Init(&err);
After these initialization functions complete, I call: NetSock_Init(err);
While debugging the recommended KAL implementation, I found that semaphore creation fails inside NetSock_Init():
p_sem = OSSemCreate(0u
if (p_sem == (OS_EVENT *)0) { *p_err = RTOS_ERR_CREATE_FAIL; return (handle); }
The eighth call to OSSemCreate(0u) specifically within NetSock_Init() returns NULL. The preceding calls return valid semaphore pointers.
OS_MAX_EVENTS = 60 OS_LOWEST_PRIO = 80
Additional debugging information – MDIO and PHY detection
I have also verified MDIO access to both the internal PCS and the external Marvell Alaska 88E1111 PHY. MDIO space 0: Internal PCS registers. MDIO space 1: External Marvell 88E1111 PHY registers.
I can successfully read the registers from both spaces. The external PHY identification registers return PHY ID1 = 0x0141 and PHY ID2 = 0x0CC2. This confirms that I can access the internal PCS and identify the external PHY through MDIO. However, the complete Ethernet packet path and ping communication are not yet verified.
TSE MAC debugging : I have verified access to the TSE MAC registers and checked the MAC configuration registers, including COMMAND_CONFIG, MAC address registers, frame length, pause settings, and inter-packet gap.
TX/RX mSGDMA debugging: I have separate TX and RX mSGDMA controllers, descriptor memory, and descriptor prefetchers configured in Platform Designer.
TSE: 0x00112000, TX mSGDMA CSR: 0x00112480, RX mSGDMA CSR: 0x001124A0, TX descriptor prefetcher: 0x00112440, RX descriptor prefetcher: 0x00112460, Descriptor memory: 0x00110000
I have verified descriptor-memory read/write access using test patterns. However, I have not yet confirmed that complete TX and RX packet transfers work correctly.
I need guidance on validating the descriptor format, buffer addresses, descriptor ownership, DMA status registers, and completion/error status. I would also like to know the recommended procedure for validating TX and RX independently before integrating them with the TCP/IP stack.
My current blocking issue is MicroC/TCP-IP initialization error 20012 (NET_SOCK_ERR_INIT_CONN_REQ_FAULT).
During debugging, I found that the eighth OSSemCreate(0u) call within NetSock_Init() returns NULL, causing semaphore creation to fail.
I would like to understand why semaphore creation fails even though the recommended networking source files are being used.
Thank you,
2 Replies
- ai_responder
Community Manager
Thank you for your inquiry. To ensure an accurate response, your request has been routed to an Altera application engineer for further review and assistance.
Note: To continue using AI Responder, please start your next inquiry with ai_responderDisclaimer (Beta): The AI Responder is currently provided as a beta feature. AI-generated responses may contain errors or omissions. Please verify technical guidance with official Altera documentation before implementation.
Thank you very much.
- JitLoonL_Altera
Occasional Contributor
Hello,
Thank you for the detailed debug notes. The MDIO/PHY ID reads and the OSSemCreate failure inside NetSock_Init() are especially useful.
Root cause of error 20012
NET_SOCK_ERR_INIT_CONN_REQ_FAULT (20012) occurs when socket-layer initialization cannot create the connection-request semaphore(s). In uC/OS-II, OSSemCreate() returns NULL when the free event list is empty. Semaphores, mutexes, mailboxes, and message queues all consume entries from the same OS_EVENT pool, which is sized by OS_MAX_EVENTS.
The failure of the 8th OSSemCreate(0u) inside NetSock_Init() typically means earlier initialization (RTOS, Net_*_Init, drivers, and application tasks) has already used most of the 60 events, so there are not enough left for the socket layer. This does not indicate a problem with the recommended Micrium source files.
OS_LOWEST_PRIO = 80 only affects the task priority range. It does not size the event pool.
Recommended fix
In os_cfg.h, increase OS_MAX_EVENTS. Try 120 or 160 first. Some full Micrium plus application setups need more.
Rebuild and confirm NetSock_Init(&err) returns success (err == NET_SOCK_ERR_NONE).
Optionally measure peak usage by logging remaining free events before and after each major initialization step, then set OS_MAX_EVENTS with some headroom.
Also confirm that other Micrium/OS limits still match your net_cfg.h settings (socket count, connection count, buffers). The immediate blocker matches event-pool exhaustion.
About Ethernet / ping
Your MDIO success (PCS plus Marvell PHY ID 0x0141 / 0x0CC2) and TSE CSR access are good signs that PHY and MAC access are working. Until the stack finishes initialization, ping will not work regardless of DMA health. Please fix OS_MAX_EVENTS first, then validate the packet path.
After stack initialization succeeds - independent TX/RX checks before full TCP/IP
1. Link: confirm SGMII / PHY link-up, and that TSE COMMAND_CONFIG has TX/RX enabled with the correct MAC address.
2. TX-only: build one TX descriptor pointing at a known Ethernet frame in memory, submit it via TX mSGDMA and the prefetcher, check DMA status/completion with no error bits, and capture the frame on the wire.
3. RX-only: arm RX descriptors to free buffers, send a unicast or broadcast frame to the board MAC from the PC, and confirm descriptor ownership flips and the buffer contents match.
Only then reconnect the Micrium interface / TSE + mSGDMA driver and retest ping to 10.0.0.2.
If you can share your os_cfg.h values (OS_MAX_EVENTS, OS_MAX_TASKS, mutex/queue enables) and your net_cfg.h socket/connection counts after the OS_MAX_EVENTS change, we can help size the remaining Micrium resources and review the mSGDMA descriptor layout next.
Thanks
JL