The lwIP_enc28j60 driver does not handle Rx buffer overflow.

[pvrfr]

Basic Infos

• [X] This issue complies with the issue POLICY doc.
• [ ] I have read the documentation at readthedocs and the issue is not addressed there.
• [ ] I have tested that the issue is present in current master branch (aka latest git).
• [ ] I have searched the issue tracker for a similar issue.
• [ ] If there is a stack dump, I have decoded it.
• [X] I have filled out all fields below.

Platform

• Hardware: [ENC28J60]
• Core Version: [Master]
• Development Env: [All]
• Operating System: [All]

Problem Description

I hope that I have done this right!

There is an intermittent going deaf condition with the Ethernet interface using the ENC28J60 module. I have done a lot of work on the ENC28J60 driver as used in the OpenSprinkler project: https://github.com/OpenSprinkler. I believe that the problem relates to the lack of a recovery mechanism for a receive buffer overflow condition.

According the the spec in section 7.2.4, if there is insufficient space in the receive buffer the RXERIF bit will be set in the EIR register. Also the BUFER bit will be set in the ESTAT register. The chip stops receiving data in this Rx overflow state. This buffer overflow condition and these error bits will not be cleared without deliberate action by the system. A soft reset is required.

There is no code in the driver that checks for the Rx overflow condition. The BUFER bit is not defined in the header file or the src file. The RXERIF bit in the EIR register is also not defined. These bits must be checked on every call to receive data.

When in a buffer overflow state, no new packets will be received and the buffer will remain empty once the previous packet has been transferred to the system. Thus, the Ethernet interface appears to go deaf.

A buffer overflow can be a frequent occurrence in some conditions. The ENC28J60 supports up to 1000Base-T Ethernet but can only communicate with the system at SPI speeds up to 20 MHz. Since there is no on-chip processing of packets (offload engine), all received data must be sent to the system for handling. This can easily overload the SPI interface and/or the system.

The simplest recovery is to call the ENC28J60::softreset() routine. But a more elegant recovery mechanism is needed.

[d-a-v]

It sounds like you could be able to help ! I integrated and quickly tested this driver but I'm not a heavy user and I take no credit for the three Ethernet drivers that I took as-is. As you may have noticed, the interface between this core and an network driver is quite light: Here's the required public and protected interface in the header (The private interface is specific to each driver).

You could:

• propose a fix as a PR
• propose a new one (embedded in the same interface)
• point us to the code of an updated or new driver

A way to reproduce the issue will be welcome so one could appreciate the benefits.

[pvrfr]

None of these drivers are mine. I got into debugging the code for my OpenSprinkler so that I could water my lawn without the unit hanging. The driver that is used is part of the UIPEthernet package. I have suggested changes there as well.

During my research I found this implementation and thought that I would point out the problem that I found.

If you want me to make the change I can do that but I have no system to test it on. If you are good with that I can add the code. It is quite simple.

[JAndrassy]

I plan to do a fix in UIPEthernet and EthernetENC library. I hope it will be simple so I thing I can then fix it here too.

[pvrfr]

Also consider checking the TXRTS bit before transmitting a packet. If the bit is set then the module is in the process of transmitting a packet. The module should be left to complete the process before attempting to transmit the next packet. Unfortunately, a change in this code will have an effect on the API since the ENC28J60::sendFrame function, as coded, will never return an error.

This is probably not a problem in most cases because the system is slower than the Ethernet channel. However if the Tx buffer is overwritten it would produce a particularly tricky bug to find.

[JAndrassy]

I plan to do a fix in UIPEthernet and EthernetENC library. I hope it will be simple so I thing I can then fix it here too.

I found out there is nothing to fix. The state bits are there for enc interrupt handling, but the libraries don't use enc interrupt.