We are using the WIZ108SR in several of our product lines to provide
RS485 to Ethernet conversion for legacy systems which output RS485 data.
While these have worked well generally, there were intermittent data
communication failures which have taken some time to pin down the cause of.
The issue was that WIZ108SR with V4.04 or earlier firmware “locked up”
if serial data was actively present when they were reset or power cycled.
The devices appeared to start correctly and they were configured as TCP
clients and made connection correctly, but no data was passed from the
serial interface to the Ethernet. Various serial data packing options of
Time, Length and Character were tried and made no difference.
It was some time before we realised if serial data was removed during startup,
then the device would make a valid connection and if data was then applied,
the serial packing options behaved as expected.
This presented a major problem for several of our systems, but the V4.05
firmware update appears to have resolved this and after testing, we no longer
see this issue.
HOWEVER, we have discovered a similar issue with this firmware which is
breaking this in a different manner.
With the V4.05 firmware, if serial data is present at power up, after the TCP client
connection is established, everything works fine, but there is a delay / lag
in the data traffic.
This is unstable and has taken some time to characterise.
The issue appears to be that any received serial data prior to the TCP client
connection being established remains in the Wiznet 108 Receive FIFO and is NEVER
cleared out, even if the incoming data connection is stopped.
If the incoming serial data stops, the socket data stops, rather than draining
the FIFO… and there is a clear delay of X number of data packets where X is
the number of packets received prior to the TCP connection coming up.
The description of the Time triggered Serial Packing mode indicates that this
should flush this out, but this is not occurring.
The result creates 2-3 seconds of data lag for each WIZ108SR in the data path
resulting in slow response from various equipments.
We were unsure if this was due to our equipment, but have replicated this with
two WIZNET108SR connected as TCP Client and Server using a serial convertor to
to inject and inspect data and the lag is seen in this test setup if data is
provided before the TCP client WIZNET108 has been powered up i.e. during it’s
boot and connection sequence. The only way to resolve this is to remove the
serial data and power cycle the device which is not acceptable in the final
system design.
Could Wiznet’s engineering team please investigate this issue and issue a
corrected v4.06 firmware as soon as possible?
If this is not resolved within 2-3 weeks, we will have to RMA our warehouse stock
of WIZNET108SR to our distributor and use a different vendor solution for this and
future products.
