I tried using the EMAC 10/100 ethernet just now with the KSZ8081 PHY using the latest nuttx master, with an updated config. It has the same problem the GMAC does– it hangs when I try to do TCP sends of more than 1446 bytes.
I'm going to look into the DMA, MAC, and PHY stuff tomorrow. I am hoping that will be easier now that I can actually debug the tcpecho thread with OpenOCD's thread-awareness. -adam On Wed, Feb 12, 2020 at 7:29 PM Adam Feuer <a...@starcat.io> wrote: > Greg, > > Yeah I get what you are saying about the driver being quite well-used. > This is a strange problem. Thank you for the ideas about the MAC > configuration, the DMA configuration, and the PHY setup. I will look into > those. I didn't even consider that the PHY could be part of the problem, > but it is a complex little chip... > > I'll look into it more tomorrow and see what I can find out. > > cheers > adam > > > On Wed, Feb 12, 2020 at 7:03 PM Gregory Nutt <spudan...@gmail.com> wrote: > >> >> > The nuttx simulator running tcpecho doesn't appear to have any problem >> with >> > large TCP sends or large number of large TCP sends. So the problem with >> > tcpecho / tcpblaster on the SAMA5D36 seems to be in the SAMA5 code >> > somewhere. >> > >> > The GMAC driver fix that I have only works when net logging is turned, >> and >> > it tested it more thoroughly today. It definitely works. But I don't >> > understand how it works, or why it doesn't work at high speeds. >> >> If the TX packets are going into DMA memory but are are never sent, then >> there could only be a few things wrong: The MAC configuration, the DMA >> configuration, or the PHY setup. I would tend to think that the PHY >> setup would be the most suspicious. That driver (in its various forms on >> different Atmel parts) has been very well exercised over many years. >> >> That doesn't mean it is error free, just not the first place I would look. >> >> > > -- > Adam Feuer <a...@starcat.io> > -- Adam Feuer <a...@starcat.io>
