-
Notifications
You must be signed in to change notification settings - Fork 84
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ESP32+W5500 corrupt TCP Packets #39
Comments
I do not use ESP, so I can not help if the problem is only on ESP32. |
I see you've already posted this same question twice on Arduino's repository. |
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. |
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. |
Please write an example code for w5500 (ethernet.h) + webserver.h |
+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. |
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? |
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 [email protected] :
…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 .
|
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, Александр Куклин <[email protected]>:
… 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
***@***.***:
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
<#39 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ARK2N575AYWZSVE2CJ2J2TDSKLDCNANCNFSM4KHD42YA>
.
|
Sounds like a bug in ESP's SPI library. Maybe report it there? |
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 [email protected] :
…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 .
|
If 3 calls to SPI.transfer(0) works, but SPI.transfer(buf, 3) fails, that is absolutely a bug in the SPI library. |
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 [email protected] :
…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 .
|
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 [email protected] :
…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 .
|
It is really possible. And this is a better solution. @PaulStoffregen but where to send this patch? |
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. |
Hi Paul. Seems like it is buggy on ESP32 SPI library...I tested with latest ESP32 framework and problem still there. |
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. |
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
The text was updated successfully, but these errors were encountered: