uCos with a DM9000A

Hello, I've just finished the DE2 DM9000A ethernet driver within uCOS.

and now I&#39;m working on the Opencore MAC driver, I think we can talk more about this. http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/smile.gif

feel free to mail me at [email protected]

We have bought 7 DE2 cards and tried the web server demo provided on the terasic web site. But we experienced problems with it.

We connected the DE2 card directly to another PC and tried it. It worked and at some point the communication stops. We tried repeated ping operations. After one minute, the DE2 card stops responding. The uCos continue to run apparently.

Since I doubt the problem could be in the lwip package or in the hardware, I suspect the driver. So I look for advice and possible solution. We have an urgent need for this.

--- Quote Start ---

originally posted by chmike@Oct 19 2006, 02:35 PM

we have bought 7 de2 cards and tried the web server demo provided on the terasic web site. but we experienced problems with it.

we connected the de2 card directly to another pc and tried it. it worked and at some point the communication stops. we tried repeated ping operations. after one minute, the de2 card stops responding. the ucos continue to run apparently.

since i doubt the problem could be in the lwip package or in the hardware, i suspect the driver. so i look for advice and possible solution. we have an urgent need for this.

<div align='right'><{post_snapback}> (index.php?act=findpost&pid=18795)

--- quote end ---

--- Quote End ---

I too tried the web server example and had similar problems...

Hello,

--- Quote Start ---

originally posted by dave@Nov 5 2006, 04:01 AM

i too tried the web server example and had similar problems...

--- Quote End ---

I am investigating the problem. The web server driver manages to initialize itself with DHCP but we have this hang after less than a minute repetitive ping operation.

Cstc1 very kindly sent me his driver that I tested thursday and friday. Unfortunately I didn&#39;t manage to make it initialize itself with DHCP, but it keeps capturing packets on the network for many minutes without hanging. I couldn&#39;t test the ping yet. I will try with &#39;hard wired&#39; ip address today.

The most important difference between the two codes is that cstc1 has made packet sending and receiving a critical section with a semaphore. Another difference is that Cstc1 interrupt handling code is simply queuing a request to process incomming data, where the web server driver read in the packet while in the interrupt code. These two difference may explain why cstc1 driver is more stable.

Though I have some doubts on its performance since it adds 20usec after reading each data out of the driver. Is that required ? The reason why it can&#39;t initialize with DHCP is also still unclear now.

cstc1 driver is also very terse in the feedback on the link up/down state or stats. But for now we look for a working solution.

--- Quote Start ---

originally posted by chmike+nov 6 2006, 12:03 pm--><div class='quotetop'>quote (chmike @ nov 6 2006, 12:03 pm)</div>

--- quote start ---

hello,

<!--quotebegin-dave@Nov 5 2006, 04:01 AM

i too tried the web server example and had similar problems...

--- Quote End ---

I am investigating the problem. The web server driver manages to initialize itself with DHCP but we have this hang after less than a minute repetitive ping operation.

Cstc1 very kindly sent me his driver that I tested thursday and friday. Unfortunately I didn&#39;t manage to make it initialize itself with DHCP, but it keeps capturing packets on the network for many minutes without hanging. I couldn&#39;t test the ping yet. I will try with &#39;hard wired&#39; ip address today.

The most important difference between the two codes is that cstc1 has made packet sending and receiving a critical section with a semaphore. Another difference is that Cstc1 interrupt handling code is simply queuing a request to process incomming data, where the web server driver read in the packet while in the interrupt code. These two difference may explain why cstc1 driver is more stable.

Though I have some doubts on its performance since it adds 20usec after reading each data out of the driver. Is that required ? The reason why it can&#39;t initialize with DHCP is also still unclear now.

cstc1 driver is also very terse in the feedback on the link up/down state or stats. But for now we look for a working solution.

<div align='right'><{post_snapback}> (index.php?act=findpost&pid=19205)</div>

[/b]

--- Quote End ---

Hi,

I did a little poking around. It seems that the board stops responding because it stops correctly receiving packets. I don&#39;t think this is a driver issue (although making changes to the driver seems to affect the frequency of the errors, not sure why). My reason for saying this:

The ethernet controller writes received packets into a circular buffer. The driver reads this buffer using a special register that slides along the buffer every time it is read (0xf2) (plus another register that just reads the value at the current position without sliding (0xf0)). When a packet is available in the buffer, the data from the current position should look something like:

01 <status> <packet length> <packet data> <crc> [next packet...]

Or when a packet is not available:

00

So after an interrupt from the ethernet controller, the driver reads the first byte (without sliding the position) to check that it is 01 before continuing. Having put some printfs in the driver code, I found that after a short while the first byte is neither 00 or 01 but some seemingly random number. This would seem to indicate that the driver had gotten "out-of-sync" with the ethernet controller in terms of the position of the sliding register, but I&#39;ve compared the packet receiving code with the datasheets and "application notes" (which basically contain example driver code) and it appears to match perfectly.

However, I added some more printfs to display the 01/00 byte, and if the byte was 01, the following status and packet length, and if the byte wasn&#39;t 01 or 00 (IE some random number), the next 200 bytes in the buffer. I then pinged the board (monitoring with ethereal), output was:

Use static IP configuration, IP =# 192.168.0.128

01 status: 0001 length: 004a

00

01 status: 0001 length: 004a

00

01 status: 0001 length: 004a

00

01 status: 0001 length: 004a

00

01 status: 0001 length: 004a

00

01 status: 0001 length: 0042

66

===========

6766 6968 fb57 2bf4 1100 08 45 3c00 456b 00 180 284e a8c0 100 a8c0 200 08 5c39 0

4 10 6261 6463 6665 6867 6a69 6c6b 6e6d 706f 7271 7473 7675 6177 6362 6564 6766

6968 45d4 f887 01 4e 9000 ae00 00 1100 cd09 1172 08 45 3c00 836c 00 180 ea4c a8c

0 100 a8c0 200 08 5c38 04 11 6261 6463 6665 6867 6a69 6c6b 6e6d 706f 7271 7473 7

675 6177 6362 6564 6766 6968 e546 270a 01 4e 9000 ae00 00 1100 cd09 1172 08 45 3

c00 dd6c 00 180 904c a8c0 100 a8c0 200 08 5c37

===========

According to ethereal, all packets sent were length 74 (4a hex), but the length of the last packet as read from the ethernet controller was 42 hex (8 less). The first 4 bytes in the buffer match those reported in ethereal as the last in the packet (with 4 byte checksum following). The next byte is then 00 as expected (to indicate no more packets). Sorry about the format of the data --- it&#39;s all little endian but printed as 16-bit ints.

I have tried inserting delays (up to 50us) between reads and writes to the ethernet controller, no difference. I can only assume this means that the data is getting corrupted either in the RAM on the ethernet controller or when it is read from the controller. I have tried lowering the NIOS system clock from 100MHz to 50MHz and playing with the settings for the PLL controlling the clock to the controller, no difference.

My board may be faulty but as you seem to be experiencing similar problems I&#39;m not so sure...

I don&#39;t really have any experience with this kind of thing so I&#39;m not sure what to try next...

Hi

sorry, didn&#39;t saw you posted an answer.

I also did many tests and found out the same result. Looking at the driver&#39;s design, it looks as if the controler appends a 0x00 after each valid packet. The driver use this to detect that there are no more packets to read. This byte gets superseeded with 01 when a valid packet is received.

The bogus situation is when the 0x00 byte is apparently not written. This is clear with your dump because the value found there is the payload of previous pings filled with increasing byte value. When the byte has the bit1 set, this triggers a reset of the controller, but when by accident bit0 and bit1 are both 0, then the driver enters an endless loop because it thinks this is value 0.

The question is thus, why this 0x00 byte is not written and in your case why it gets a packet with invalid length. Which is worse.

Here is more info on the two first status bytes of pakets I found out. Unfortunately they are not documented in the data sheat I have. Lets call the two first bytes of the packet header S1 and S2.

niosIIuser apparently had knowledge on some of the S2 bits that he tests in his driver. bit 7 = length err , bit 5 = crc error, bit 4 = Fifo overflow. I noticed that bit 6 is on when the packet is an ARP multicast packet. It could signal Ethernet multicast packets. No info on other bits.

I beleive the S1 bits have the following meaning: bit0 = valid packet avail, bit 1 = 0, bit2 = ip packet, bit3 = TCP packet?, bit4=UDP packet.

I have three drivers and all drivers are quite different in the way to handle packets. Only the web server driver rely on the 0x00 byte value after a packet.

--- Quote Start ---

originally posted by chmike+nov 8 2006, 06:25 pm--><div class='quotetop'>quote (chmike @ nov 8 2006, 06:25 pm)</div>

--- quote start ---

hi

sorry, didn&#39;t saw you posted an answer.

i also did many tests and found out the same result. looking at the driver&#39;s design, it looks as if the controler appends a 0x00 after each valid packet. the driver use this to detect that there are no more packets to read. this byte gets superseeded with 01 when a valid packet is received.

the bogus situation is when the 0x00 byte is apparently not written. this is clear with your dump because the value found there is the payload of previous pings filled with increasing byte value. when the byte has the bit1 set, this triggers a reset of the controller, but when by accident bit0 and bit1 are both 0, then the driver enters an endless loop because it thinks this is value 0.

the question is thus, why this 0x00 byte is not written and in your case why it gets a packet with invalid length. which is worse.[/b]

--- quote end ---

in my case i have found that the 0x00 byte does get written, but because the packet length is reported incorrectly, not enough bytes are read to reach the 0x00 byte, instead we end up half-way through the packet! (this is what i was trying to show with my previous post)

<!--quotebegin-chmike@Nov 8 2006, 06:25 PM

here is more info on the two first status bytes of pakets i found out. unfortunately they are not documented in the data sheat i have. lets call the two first bytes of the packet header s1 and s2.

niosiiuser apparently had knowledge on some of the s2 bits that he tests in his driver. bit 7 = length err , bit 5 = crc error, bit 4 = fifo overflow. i noticed that bit 6 is on when the packet is an arp multicast packet. it could signal ethernet multicast packets. no info on other bits.

--- Quote End ---

Yes, bit 6 does indeed signify multicast --- according to a line in the "Application Notes" datasheet, this status byte is the same as the RSR register (RX status), which is described on page 16 of the other datasheet.

--- Quote Start ---

originally posted by chmike@Nov 8 2006, 06:25 PM

i beleive the s1 bits have the following meaning: bit0 = valid packet avail, bit 1 = 0, bit2 = ip packet, bit3 = tcp packet?, bit4=udp packet.

--- Quote End ---

I can&#39;t find any information about these bits in the datasheets... although one line does imply that they should all be 0 except the 1st bit:

"The first byte is used to check whether a packet is received and filtered in the RX SRAM. If this byte is "01", it means there is a packet received. If this byte is "00", it means there is no packet received in the RX SRAM."

However, everywhere else (including the example code), it just checks the first 2 bits. In my testing, I have found that (before the incorrectly received length causes it to break), this byte is always "01" or "00". You have different results?

--- Quote Start ---

originally posted by chmike@Nov 8 2006, 06:25 PM

i have three drivers and all drivers are quite different in the way to handle packets. only the web server driver rely on the 0x00 byte value after a packet.

<div align='right'><{post_snapback}> (index.php?act=findpost&pid=19304)

--- quote end ---

--- Quote End ---

--- Quote Start ---

originally posted by dave@Nov 8 2006, 09:44 PM

in my case i have found that the 0x00 byte does get written, but because the packet length is reported incorrectly, not enough bytes are read to reach the 0x00 byte, instead we end up half-way through the packet! (this is what i was trying to show with my previous post)

--- Quote End ---

Yes, it seems that the packet data is not fully written to ram. We get whatever garbage was there before. In your case you even get an incomplete packet.

I activated packet rejection if the crc is not valid. So I "loose" packets in fact and don&#39;t see the case of incomplete packets. Though I see the case where the previous packet is complet and valid, but the byte 0x00 is not written.

Have you tried adding a delay before setting idx to 0xF0 ? The driver I have at hand doesn&#39;t have this but who knows ?

I must also report that in some situation the OS freezes. Though it is much less frequent than the incomplet packet.

Regarding S1 bits, I confirm that only bit0 and bit1 are to be taken in account to check the status. In the driver they will use a mask of 3 to check their value. Must be 0 or 1, if its 2 or 3 then something is bogus.

niosIIuser is also using DE2 card but not the uCOS so I could not use his driver straigh away. It works differently, but most settings are the same. He doesn&#39;t rely on the 0x00 byte at the end to detect end of packet sequence. Another strange thing is that he use a 32 mapping and not a 16 as you and me are apparently using. I don&#39;t know how this can interfer.

I was wondering if the EEPROM is in use and could somehow interfer ? Do you know how to dump the EEPROM content ? There seem to be alot of parameters in there. I didn&#39;t understood what they all mean.

We have 7 cards and one is much more stable than the others while the code is exactly the same. It was reported to me, I didn&#39;t test it myself. So if there is a difference in the EEPROM content it could explain the different behaviour.

Any hint fron the retailer ?

The 6 most significant bits of S1 correspond to the 6 most significant bits of register 0x32 if CRC check has been enabled. S2 is a copy of register 0x06.

If you set bits asking to reject packets with invalid CRC, this eliminates truncated packets. But from time to time we get a packet with a valid CRC but the byte 0x00 has not been written. What is more strange is that even if a good packets arrive after it, the 0x01 is not written.

To enable rejection of packets with CRC errors, there are apparently two bits to set. One in register 0x32 and one in register 0x05. Though this result in packet loss.

Now I see that the uCOS crashes are becoming more frequent. Don&#39;t know here this comes from.

Hi again, sorry I haven&#39;t replied, I didn&#39;t get an email about your responses (even though I am subscribed to this thread) :/

I have found a solution to one of the problems (the data being read incorrectly from the SRAM on the ethernet controller). I have replaced the verilog interface that simply wires up the avalon slave to the ethernet controller with a simple state machine to ensure the timing constraints described in the datasheet are adhered to. With this fix, the driver no longer gets out of sync with the controller after a while, and everything is considerably more stable (I left my PC pinging the board overnight -- 20,000 responses, 0 lost)

However, there is still a problem when there is a fair bit of traffic to/from the board. I think I have identified the cause (a bug in the output routine of the driver). I will fix this bug and post the changes I have made once I verify that everything is working...