What is your experience of the FSU Ethernet capability?
I’m finding that if a direct link is made it all works fine as expected. If it is on an isolated network with two machines, it’s generally OK, but if its on a network with any sort of traffic it’s response slows down sometimes to a standstill. Pings to the FSU have wildly varying return times, some failing all together. Attempts to log in to my TCP/IP server (on the FSU) usually time-out and otherwise responses are slow in coming back from the FSU.
Is anyone using Ethernet successfully in real world applications?
No one using Ethernet then? lets scrub the successfully bit 
No, I haven’t tried to use ethernet at all on any Wavecom device. I haven’t even looked at it.
Thanks awneil, looks like I’m on my own so far.
I’ve had hints from support that there are known problems but no indication if anything is going to be done about it or any willingness to persue it. 
Without other experience I don’t know if its “just me” or others are getting on fine.
I have a dev kit and I created a ethernet adapter using spi and a microchip controller and works fine.
i.e. you didn’t use any of the Wavecom implementation of the ethernet protocol and drivers?
Re-engineering the Fastrack is not really an option at the moment, but glad to you had success there.
I think the Wavecom implemetation has problems filtering out packets not intended for it. i.e. doesn’t filter it, so the software gets swamped with irrelavent data.
Hello,
We are using FSU 10 with IESM Ethernet card/firmware 7.3/open AT 6.21/WIP 5.10.
We base on ethernet driver sources shipped as a sample with WIP Plug-In 5.10.
I didn’t run any stress tests emulating bad conditions in LAN,
but FSU with Ethernet was plugged into our intranet around one month ago,
and up to now it works stable.
Thanks for sharing your experience. I might have to do some more testing.
We use Ethernet quite heavily.
There are some issues with advanced features in WIP (TUN interface is broken under certain routing conditions, for example).
Also, ENC28J60 driver provided by Wavecom is very badly written, although it somehow manages to work most of the times. I had to do some changes to get it to work faster and more reliable. Still waiting on Sierra Wireless to provide resolution to (hopefully) last problem with it.
Rudolf Ladyzhenskii
SymStream
I am also using Ethernet on a Q2687.
The following features of my application use the Ethernet:
- I host an embedded web server
- I host a DHCP Server
- I use the Q2687 as an internet gateway for a network
The Ethernet driver was stable when I wasn’t using the device as an internet gateway but since I have it has been a total mess. The driver dies giving errors like: [ENC28J60] tx error (ESTAT=83), TX watchdog and RX error. It dies randomly, sometimes only dying after 20 mins of usage, other times after 5s of usage.
Anyone else having stability problems with the Ethernet driver?
Are you willing share your improvements?
This is what I got in a PM:
Hi,
I can not send you our version of a driver, because we added TAP capability to it to work around other issues. It is heavily modified to suit our app. And, on its own, it will not compile into your code.
I can give you few points, though:
- In ISR, you will see that drivers adds 200ms sleep on each call (about line 523). The way they used #defines around the code is plain wrong. Code is executed every time.
- Use of ReadBuffer and WriteBuffer variables. Variable re-use may be a good thing, but not the way Wavecom did it. Basically, they re-use those globals and this corrupts Rx buffer pointers. Just look for all instances of those variables and replace with locals.
- drv_timer() function checks Link status way too often. Should be sufficient to check it every few seconds.
This should get rid of most problems
Rudolf Ladyzhenskii
SymStream
The manual for adl_busWrite says NOT to use local variables, so seem like a bad advice (unless the original pm-er knows more about openat internals). If somebody can explain why it is ok to ignore the manual, please comment.
“pDataToWrite should point to either a global static or dynamic buffer. Stack variables should not be used to hold data to bus services. If the write is synchronous, the data buffer may be released or reused after the adl_busWrite API call. For asynchronous access, the application should wait for the confirmation via the interrupt event before releasing the buffer.”
It does - but it is not quite correct!
What it should really say is that Automatic variables should not be used; ie, only global or static variables should be used, or dynamically-allocated memory.
Yes, it is bad advice because it does not make clear that any locals used must be static!
ie, not Automatic.
It’s not really about Open-AT internals - it’s about the way that compilers work.
Automatic variables are almost universally allocated on the stack - so, as soon as the function in which they were declared returns, they are no longer available for use.
If you pass a pointer to an automatic variable, and something makes use of that pointer after the function in which the automatic variable was declared has returned, then it will be accessing the memory where that variable used to be - but that memory will now be in use for something else!
If you are “lucky” i[/i], that might just lead to data corruption - but it could equally end up corrupting the stack and causing the application to crash drastically!!
It is not safe.
If you follow that advice, you will be safe
Perhaps what they meant to write was:
(note the extra comma)
This is correct.
Local variables will be on the stack unless they are qualified as ‘static’
(local variables not qualified as ‘static’ are known as “automatic”)
One of the issues I had (there is always more than one source to a complex problem 
) was that the Supreme extender card (IESM ) for Ethernet did not have a copper earthing plate fitted, so the earthing was poor. This copper clip sits on the back of the face-plate, clips through the face-plate of the USB hole, and presses against the earth plane on the IESM. That led to alot of our problems.
We did still see poor performance on busy networks, but this seems to have been eliminated moving to the Xtend platform with the newer firmware.
Is that a design fault in all the Ethernet IESMs, or was the tag just missing on your particular IESM?
I think the early versions (which didn’t have the clip) suffered problems, so the new faceplate with clip was issued, and presumably the IESM board had a grounding space added.
What I know for sure is our faceplate had the tag missing but the IESM did have the grounding point, and with the new face-plate it suddenly started behaving normally (apart from the heavy network load issue).
The case you mention of course holds for the asynchonous write / reads. The code in question, \WIP\samples\Libraries\ethernet_driver\src\drv_enc28j60.c uses synchronous bus writes / reads and hence are fine with the lifetime of the buffer being limited to the lifetime of the caller.
The manual does not pose the mentioned requirement only on asynchronous calls but as a general requirement for using these functions. Therefore I refered to openat internals, since they might exploit properties of the global static / dynamic memory (e.g. alignment / DMA addressable / protection ???).
I guess that is not the case, hence I am posting here, so perhaps someone from SiWi can comment on it and mention that it IS fine to use buffers on the stack for blocking write / reads. And if he/she is in a good mood, adjust the manual accordingly. Until that happens I guess it is better to stick to the manual.
I tend to think the same. But what makes me wonder is that SiWi poses restriction on the memory types in the first place. If the intention of the note is to make the caller aware that the buffers must remain, why not note that instead…?
Thanks for sharing, that seems like a more reallistic solution then moving variables around. Will get me a screw driver … 
edit:
I have a faceplate with clip 
I think Open-AT internals might start to come in here:
It’s possible that parts of the code might be running in different “execution contexts” (wahatever that may mean) - some of it completely outside of ADL - and it might not be allowed for one “context” to access the stack of another…
This is just speculation on my part.
At least if you stick to the “no Automatics” rule, you know you’ll be safe!