Forum Discussion

ChandanHm6360's avatar
ChandanHm6360
Icon for New Contributor rankNew Contributor
1 day ago

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's avatar
    ai_responder
    Icon for Community Manager rankCommunity 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_responder

    Disclaimer (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's avatar
    JitLoonL_Altera
    Icon for Occasional Contributor rankOccasional 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