Embedded Ethernet Development Kit & ex_st_webserver.c ex

[anbeyon]

Hi All

I am a Newbie with some of this. (I know PICs, I know C, I know TCP/IP but not TCP/IP on PICs)

I have been playing with the CCS board I have. http://www.ccsinfo.com/product_info.php?products_id=embethkit with PIC-C compiler and thier version of the TCP/IP Stack.

I have been working through some of the various examples and am now investigating their web server example ex_st_webserver.c

I have it running and have not yet made any changes to it. However, it does not run for very long before the TCP/IP/HTTP web part grinds to a halt. The Serial user interface for IP config contines to work without problem and the board continues to toggle the RED LED at 1 second intervals but the web part stops working.

Does any one here use the PIC-C compiler and CCS version of the TCP/IP Stack ?

Have you played with this example - did it work for you ?

Are there any issues in the CCS version of the stack that can cause this ?

I am using the TCP/IP stack as upplied with PIC-C version 3.429

Any hints, tips, suggestions would be appreciated.

Thanks

Anbeyon

[asmallri]

I have played with this stack (not sure of the version) and observed the same problem. For a number of reasons, I now use my own stack.

You need to check if your version of the the stack code correctly handles the ENC28J60 Rev B4 Errata. Specifically the issue related to the Receive Packet Interrupt flag. There is a silicon bug that prevents this flag from being reliably set. The result (if you use only this flag) is the packet stays in the receive buffer until some other event (subsequent network activity) results in the flag being set. Unfortunately a TCP session may (and often does) time out before this event.

There is a work around for this problem described in the Errata.

I do not know if the current CCS implementation of the stack has this work around, you will need to look at the source.

BTW - there is an Ethernet bootloader for this board on my site. It is free for non commercial use.
_________________
Regards, Andrew

http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!!

[Douglas Kennedy]

I don't have the CCS code so I don't know if it is buggy or not but even if it is perfect the PIC has limited RAM.
TCP as you know stands for Terminal Control Program, each packet contains an initial random sequence number that is incremented by the payload byte count per socket. The send and receive packets begin with different initial random numbers and are incremented appropriately. TCP provides for packets to arrive out of sequence ( this allows for different interpacket routing over the web perhaps resulting in out of sequence arrival times) and to be appropriately sequenced upon receipt. The PIC with limited memory will not be able to resequence these packages. There is a ring buffer in the network interface hardware but it is operating at the MAC level and knows little about the TCP/IP packet. I've always added an external DRAM to the PIC side of my TCP/IP projects to store inbound packets for possible resequencing and to store outbound packets that might need resending. The NIC handles ethernet collision resends but a TCP on the web can NAK a packet in software requiring a resend. This can happen because an external interrupt steps on the priority of the received packet interpretation software there are many other possabilities. I'd put a packet sniffer into your path to see if packets are flowing seamlessly or not, pay particular attention to the NAK's sequence numbers and the PIC's response within CCS's code.

[anbeyon]

Darren just wondered if you had any comments regarding wether or not the CCS version of the TCP/IP had been adjusted for ENC28J60 rev b4 silicon

Anbeyon

[treitmey]

[rmozer]

I had a simular problem with TCP using the Microchip stack as ported by CCS. With a limited amount of ram, the code has a "feature" that allows TCP packets to be sent with out waiting for the ACK. There is a performance penalty but you can set:

#define TCP_NO_WAIT_FOR_ACK FALSE

(In hardware.h) This will cause the stack to wait for an ACK on each TCP packet when set to false. You might give it a try and see if he helps with your web server as well.

[asmallri]

[anbeyon]

Thanks to all that have posted so far!!

I will try what rmozer suggests and see what happens - thanks.

Andrew if you discover anything will you also post back here please.

Thanks

Anbeyon

[anbeyon]

Hi rmozer

I have searched files in the CCS stack fro occurences of TCP_NO_WAIT_FOR_ACK FALSE and can't find anything.

Am I looking in the wrong place ?

Thanks

Anbeyon

[asmallri]

OK so my memory was not failing me.

Here is an extract from RFC793 - Transmission Control Protocol

[anbeyon]

Ignore me - got my search wrong - did it just before rusging out of the door.

I'll try again :0)

Thanks

Anbeyon

[anbeyon]

Hi

just tried setting TCP_NO_WAIT_FOR_ACK to FALSE

Doesn't seem to have made much difference to the problem I'm having. With web server function grinding to a halt.

All else continues to function


If anyone has any other ideas I can try please let me know.

Thanks

Anbeyon

[Douglas Kennedy]

The PIC as the server has to be able to immediately handle the resizing of the client window. The project I experimented with in 2003 had the PIC serve several large jpg files as part of a web page ( stored on an MMC).
The server downloads the web page html file with embedded image files ( jpg) and the client sends multiple GETS for the Jpg's back to the server which then in turn downloads the jpg files. Streaming a large file down to the client made it very probable that the client would be resizing its socket window (window flow control).
Use a packet sniffer ( I use Etherreal) and pay special attention to sequence numbers and flags close to the point you get the freeze.
Transmission Control Protocol/Internet Protocol TCP/IP is a dance of exchanged sequence numbers and flags with each flag requiring a prescribed response.

[anbeyon]

Thanks Douglas,

All 'm trying to do is evaluate the CCS tools and stack and so all am doinf right now is compile a supplied example and run it.

Am I being foolish in thinking that it should just work. Afterall I am using CCS dev tools, CCS ported stack STACK and CCS example.

The only room for error as far as I can see and as Andrew pointed out earlier is that;

1. Since the Stack was first ported by CCS it has not kept up with bug fixes microchip have introduced into thier stack.

2. That the stack does not include workarounds for Silicon changes/errata.


I'm not expecting my project to be trouble free but was rather hoping that I should be able to take a simple example and make it run reliably. Currently that doesn't happen.

Thanks again

Anbeyon