Forum Discussion
Altera_Forum
Honored Contributor
20 years agouCos with a DM9000A
Hi Everyone Has anyone ever used uCos TCP/IP stack with the DM9000A ethernet MAC+PHY (Davicom) ? This is for the DE2 board sold to universities by Altera. If anyone has experience on interfac...
Altera_Forum
Honored Contributor
19 years ago --- 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'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'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'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'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'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'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 ?