This section describes the process for debugging the MAC port.

1. Step 1: When link never establishes after initialization.
   1. Begin by verifying the MAC port opened successfully.
   2. Set a breakpoint at the Enet_open() function and step through to the return value. ENET_SOK indicates success, but you must also verify the MAC port handle is non-NULL.
2. Step 2: After the Enet_open() function succeeds.
   1. Set a breakpoint at the EnetMacPort_open() function or the port-specific variant like the Cpsw_openPort() function.
   2. Inspect the macCfg parameter before the call executes.
      
      Note: The macCfg.layerType field must match your hardware configuration exactly: ENET_MAC_LAYER_GMII_RGMII for RGMII interfaces or ENET_MAC_LAYER_RMII for RMII.
      
      
   3. Check the linkCfg.speed and linkCfg.duplexity fields.
      
      Note: If these fields are set to fixed values like ENET_SPEED_100MBIT and ENET_DUPLEX_FULL, but your link partner or PHY is configured for automatic negotiation, link never comes up. The most reliable approach is setting the speed to ENET_SPEED_AUTO and the duplexity to ENET_DUPLEX_AUTO, then letting the PHY handle negotiation. A mismatched speed or duplex between the MAC configuration and the PHY capability causes perpetual link-down states.
      
      
3. Step 3: When link appears established in the PHY registers but no traffic flows.
   1. Verify the MAC port is actually enabled.
   2. Set a breakpoint at the Cpsw_enablePort() function, or equivalent, after link-up is detected.
      
      Note: If this function is never called, your link status callback is not triggering port enable, which is required even after a successful MAC initialization.
      
      
   3. Check the return code from the Cpsw_enablePort() function.
      
      Note: ENET_EPERM indicates the port was already enabled, which is harmless. ENET_EINVALIDPARAMS means the port number or configuration is wrong. A frequent configuration error is enabling the MAC port before the PHY reports link-up. The MAC port must remain disabled until the PHY link callback fires and confirms link establishment. Enabling the port prematurely causes the MAC to transmit into a disconnected PHY, resulting in dropped packets and no error indication.
      
      
   4. Set a watch point on your link status variable and verify the point transitions to true before the cpsw_enablePort() function is called.
      
      Note: If the sequence is reversed, restructure your initialization to wait for the PHY link-up before enabling the MAC port.
      
      
4. Step 4: To verify correct MAC port configuration after initialization.
   1. Read back the port registers using the debug console or a memory browser.
      
      Note: The MAC mode register shows the interface type matching your hardware. The MAC control register indicates the port is enabled only after link-up. If these registers show unexpected values, the MAC configuration structure was not applied correctly, possibly due to using a default configuration instead of the hardware-specific settings. Always explicitly set the layerType, speed, and duplexity fields rather than relying on structure initialization defaults. When link is up and initialization succeeds, but the transmitted packets never appear on the wire, the problem lies in the TX submission path or DMA descriptor management.
5. Step 5: Checking the packet queue
   1. Set a breakpoint at the EnetDma_submitTxPktQ() function in your transmit function.
   2. Examine the packet queue being submitted before the call executes.
   3. Check that the queue count is non-zero by inspecting the internal queue structure.
      
      Note: If the queue is empty, the problem is earlier in the code where the dequeue packets from txFreePktInfoQ. A common bug is calling the EnetQueue_deq() function on an exhausted free queue and not checking for a NULL return value, then attempting to submit an invalid packet pointer.
6. Step 6: If the packet queue is valid.
   1. Inspect each sgList structure of the packet.
      
      Note: The first bufPtr of the segment must point to valid memory containing the Ethernet frame, and segmentFilledLen must equal the frame length. A common mistake is setting segmentFilledLen to the maximum buffer size instead of the actual frame length. This mistake causes the DMA to transmit garbage padding bytes, which potentially exceed the MTU and get dropped by the PHY or link partner.
      
      
   2. Step through and verify segmentFilledLen is between 64 and 1518 bytes for standard Ethernet frames.
7. Step 7: After the EnetDma_submitTxPktQ() function returns.
   1. Check the status code.
      
      Note: ENET_SOK means the submission succeeded. ENET_EINVALIDPARAMS indicates the packet structure is malformed. ENET_ENOMEM means the DMA descriptor ring is full, which happens when transmitted packets are not being retrieved and freed.
      
      
   2. Set a breakpoint in the EnetDma_retrieveTxPktQ() function and verify this function is called regularly, typically from a periodic timer or after each transmit.
      
      Note: If this function is never called or called too infrequently, the TX descriptor ring fills up and transmission stops silently.