I’m trying to add Ethernet to an existing application using FreeRTOS and I’m running up against what appears to be a GMAC problem with the SamDriver.
The board has a SAM4E processor with a DP83822H PHY. I added the DP83822H ID to the appropriate places in phyHandler and the PHY seems to be working fine. I can see the auto negotiation succeed, the link status goes up and the switch the device is connected to also shows the link.
However, I don’t get any packets when I try to send ping. The only interrupt I get on the GMAC is HRESP, which as far as I can tell means there is something wrong with the DMA. I get one of these interrupts about every 10 seconds.
I’ve dug into the driver and the only thing I thought might be an issue was the DMA Receive Buffer Size being set to 1536 without also setting the MAXFS bit in GMAC_NCFGR. The docs say the GMAC will discard frames greater than 1518 by default. However, setting that bit and/or reducing the buffer size didn’t change anything.
Has anyone else run into this issue? Any help tracking down what the issue is would be appreciated. If there is an up to date minimal example for SAM4E that could help too. I was unable to find one when starting this project.
Besides memory size, have you checked the requirement of buffer alignment? For example, refer to LPC18xx, it requires us to provide 4-bytes aligned buffer for the interface.
It is also important to make sure that the DMA-related buffers are located in non-cacheable memory.
You might want to have a look at my SAM4E example. Do not try to compile it (has not been maintained for years), but it might show a difference with your code.
sam4e_flash.ld is interesting: it defines .first_data, an area at the beginning of SRAM.
For instance, check where DMATxDscrTab[] is located (in ths xxx.SYM file). Is it set into .first_data?
One user wrote me about his SAM4E project:
"I have made progress! Finally!
I had not defined “.first_data” in my linker script, that fixed the problem with ASF3 project and I was able to ping the controller. This however, did not work with the ASF4 (Amel Start) project, eventually I had to null all the remaining 4 priority buffer descriptors, including the rx ones as well. This is how they did it in the new ASF4 GMAC driver by the way.
Check lines 158-173 in attached “gmac_SAM.h” and 261-268 and 310-318 in attached file gmac_SAM.c
I am going to upload both projects (ASF3 and ASF4) as working Demos on the forum soon, I think it will save people a lot of time. There are minor differences when using ASF4, mainly including of “utils.h” and using “peripheral_clk_config.h” instead of <sysclk.h> in “NetworkInterface.c”
I am very thankful for your much appreciated help."
Looks like alignment was the issue. I added the .first_data definition to my linker script and now I am getting ARP packets and RCOMP interrupts. It doesn’t reply to pings yet, but that is a different issue to dig into.
It doesn’t reply to pings yet, but that is a different issue to dig into.
I guess that you have set these 2 config macros:
/* If ipconfigREPLY_TO_INCOMING_PINGS is set to 1 then the IP stack will
generate replies to incoming ICMP echo (ping) requests. */
#define ipconfigREPLY_TO_INCOMING_PINGS 1
/* If ipconfigSUPPORT_OUTGOING_PINGS is set to 1 then the
FreeRTOS_SendPingRequest() API function is available. */
#define ipconfigSUPPORT_OUTGOING_PINGS 1
Can you try pings in both directions? Maybe you can post a zipped PCAP file to show the packets?
Maybe you can step through the code and see how far it gets?
I had a chance to dig into this. Stepping through the code I can see that the received ping is processed and a reply is generated, loaded up and transmission is started by setting GMAC_NCR_TSTART but the transmission never seems to complete and nothing is sent. I can also see in the GMAC_TSR register that TXGO is set, so the GMAC does appears to be trying to transmit.
Another thing of note is that eventually the pool of TX descriptors is exhausted. Since the transmission never finishes, the semaphores never get freed.
I do have incoming set but not outgoing. The application doesn’t need to send outgoing pings, so I didn’t have that set. That shouldn’t affect replies to incoming pings though, right?
I’m starting to suspect this might be something wrong with the custom board or perhaps something is not being configured correctly for this particular PHY/GMAC combo. I’ll continue to work at it. Appreciate the help!
Following up. My remaining issues were hardware related. After much troubleshooting I hit a wall, so I dug out an old SAM4E dev board I had laying around and everything worked fine. I requested another unit to test on and thankfully the issue is limited to this one board and doesn’t appear to be a design problem with our custom hardware.
Thanks again for all the help, very much appreciated.