PaulStoffregen / Ethernet

Ethernet library for Teensy (Wiznet W5100 / W5200 / W5500)
http://www.pjrc.com/teensy/td_libs_Ethernet.html
130 stars 83 forks source link

ESP32+W5500 corrupt TCP Packets #39

Open ale-trevizoli opened 4 years ago

ale-trevizoli commented 4 years ago

Hi Paul! I'm using your library for long time and I love it, but now I migrate some codes to ESP32 with W5500 (berfore I using MEGA2560+W5100), but on W5500 some random times I'm getting corrupt tcp data packets, so in WEBSERVER sample, if we make a lot of refresh pages in Browser we get corrupt characters on page. I tried to use ESP32+W5100 and ESP32+W5500 with OLD Ethernet2 library and it's not happen. Could you help me to fix it? You can simulate only taking ESP32+W5500. I'm using pins GPIO 5(CS),18(CLK),19(MISO) and 23(MOSI). W5500 Module: https://ae01.alicdn.com/kf/H6e6dbc78b77c493fb11edd8e8fa3f4aec/USR-ES1-w5500-chip-novo-spi-para-lan-ethernet-conversor-tcp-ip-mod.jpg

PaulStoffregen commented 4 years ago

Could you help me to fix it?

I do not use ESP, so I can not help if the problem is only on ESP32.

PaulStoffregen commented 4 years ago

I see you've already posted this same question twice on Arduino's repository. https://github.com/arduino-libraries/Ethernet/issues/120 https://github.com/arduino-libraries/Ethernet/issues/124

ale-trevizoli commented 4 years ago

Sorry Paul, I tried to put this information o arduino-libraries too, to get some quick answer. I'm finishing one long time project and now I have this bug. I really don't know if this is a ESP32 problem or if is an Library problem, what I know for searching on internet is that have some Registers are wrong on library like explained on this issue link: https://github.com/arduino-libraries/Ethernet/issues/84 . But I cannot say if is the root cause of this problem (is out of my capacity). I hope someone can say it. About ESP32, based on my experience, since Ethernet2 library don't have this issue, using exactly same code, only changing ethernet.h to ethernet2.h, have a good chance to be something on library, what you think? Have two problems to use Ethernet2 library, this is old and not maintained, and have another bugs on it. But I'm not have enough knowledge to point where is this error on Ethernet library, only think I can say is Ethernet2 library not show this same error on same code and same hardware. Other think that I could check is with W5100 not show this error too. But now I have 100 units of W5500 ready to use on this project, so I'm trying to work to fix it. Sorry my poor english, I'm from Brazil.

PaulStoffregen commented 4 years ago

Do you have a Teensy board? Can you reproduce the problems with a Teensy?

I will not spend time testing ESP32. But if the problem can be reproduced with Teensy, I will investigate.

workpage2 commented 4 years ago

Please write an example code for w5500 (ethernet.h) + webserver.h Everything works with wifi, but it doesn’t work with ethernet.

Alexandr-zz2not1 commented 3 years ago

+1 get same problem. In ethernet2 no bugs, in ethernet some packet's have mistakes. I thought it was problem of electric design, but ethernet2 work fine. Any webserver example get unreadable parts of text or html or payload data, some times it'just happen :-/. Esp32+w5500 ethernet.h it seems like there are some problems in transport. P.s. I use that config to download update from another server to esp32 - waiting for problems. May be problem is only in outgoing from esp32 traffic.

PaulStoffregen commented 3 years ago

I am not maintaining Ethernet for non-Teensy boards. If this problem is only on ESP32, I do not intend to investigate.

Maybe someone else will take the time to test on ESP32 and find the cause of problems?

Alexandr-zz2not1 commented 3 years ago

Ok. Thanks for unswer. Just looking for information. About library - it's cool tool. Try to find out something. Sorry for disturb.

Отправлено из Mail.ru для Android понедельник, 12 октября 2020г., 16:21 +07:00 от Paul Stoffregen notifications@github.com :

I am not maintaining Ethernet for non-Teensy boards. If this problem is only on ESP32, I do not intend to investigate. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub , or unsubscribe .

Alexandr-zz2not1 commented 3 years ago

so, I find some.. ...\utility\w5100.cpp-> uint16_t W5100Class::read(uint16_t addr, uint8_t *buf, uint16_t len): ... [code] SPI.transfer(cmd, 3); memset(buf, 0, len); SPI.transfer(buf, len); resetSS();

[/code] ... looks like esp32 is 32bit and doing something wrong when we ask memset() or something else. Ethernet2.h use [code] SPI.transfer(cmd, 3); for (uint16_t i=0; i<len; i++){ buf[i] = SPI.transfer(0); } resetSS();

[/code] and that works fine. no problem now. -_-

пн, 12 окт. 2020 г. в 17:03, Александр Куклин dizz34all@gmail.com:

Ok. Thanks for unswer. Just looking for information. About library - it's cool tool. Try to find out something. Sorry for disturb.

-- Отправлено из Mail.ru для Android понедельник, 12 октября 2020г., 16:21 +07:00 от Paul Stoffregen notifications@github.com:

I am not maintaining Ethernet for non-Teensy boards. If this problem is only on ESP32, I do not intend to investigate.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/PaulStoffregen/Ethernet/issues/39#issuecomment-706997331, or unsubscribe https://github.com/notifications/unsubscribe-auth/ARK2N575AYWZSVE2CJ2J2TDSKLDCNANCNFSM4KHD42YA .

PaulStoffregen commented 3 years ago

Sounds like a bug in ESP's SPI library. Maybe report it there?

Alexandr-zz2not1 commented 3 years ago

May be.. But spi working fine in my application. In that sketch, and no problem. I think if they have bug, they will find it. So for now, problem is only here. It is not big deal change 1 function. If spi lib change - may be brakes somthing else :-). Since SPI is in ESP32 core, i think it wold be easier find problem in much large problems. In my experience errors was rare. And i have not that much skill, to find problem in SPI.))

Отправлено из Mail.ru для Android воскресенье, 18 октября 2020г., 15:02 +07:00 от Paul Stoffregen notifications@github.com :

Sounds like a bug in ESP's SPI library. Maybe report it there? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub , or unsubscribe .

PaulStoffregen commented 3 years ago

If 3 calls to SPI.transfer(0) works, but SPI.transfer(buf, 3) fails, that is absolutely a bug in the SPI library.

Alexandr-zz2not1 commented 3 years ago

I don't mind) may be there are something more else. Anyway. I just findound the bad place, simple fix it. If someone will find another route: add some libs or fix typos, add definition.. it would be cool)

Отправлено из Mail.ru для Android воскресенье, 18 октября 2020г., 15:45 +07:00 от Paul Stoffregen notifications@github.com :

If 3 calls to SPI.transfer(0) works, but SPI.transfer(buf, 3) fails, that is absolutely a bug in the SPI library. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub , or unsubscribe .

Alexandr-zz2not1 commented 3 years ago

Could it be, that memset doing before spi can transmit data, and some of buf became corrupted? Now i add yield(); before memset. And problem don't appear.

Отправлено из Mail.ru для Android воскресенье, 18 октября 2020г., 15:45 +07:00 от Paul Stoffregen notifications@github.com :

If 3 calls to SPI.transfer(0) works, but SPI.transfer(buf, 3) fails, that is absolutely a bug in the SPI library. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub , or unsubscribe .

uzi18 commented 3 years ago

It is really possible. And this is a better solution. @PaulStoffregen but where to send this patch?

PaulStoffregen commented 3 years ago

memset is a standard C library function. SPI.transfer(buf, length) is a function defined by Arduino's SPI library. These features should work on all Arduino compatible boards.

If either is failing on ESP, it a bug with the ESP software which should be fixed in the ESP software. This is not a bug in Ethernet. Please report it to the ESP developers, so they can fix either SPI (likely) or memset (very unlikely to be buggy).

Again, these are standard functions which should work on all Arduino compatible boards. Ethernet is not the problem.

ale-trevizoli commented 3 years ago

Hi Paul. Seems like it is buggy on ESP32 SPI library...I tested with latest ESP32 framework and problem still there. I made corrections suggested by Alexandr and it really solve the problem...I will try to show it to ESP32 community. I know that you not like ESP32. Anyway I'd like to thank 's Alexandr for discovery because I was searching for this problem for months...

PaulStoffregen commented 3 years ago

I do not believe libraries like Ethernet should have to use the much slower 1 byte function for all boards, or include special ifdef checks, only because the faster block transfer is broken on 1 type of board. The ESP developers need to fix their SPI library.