[BUG] Several new issues with ESP3D V3.0 September 2024 update #1047
Comments
|
For point 1 : ESP32 pin definitions changed https://github.com/espressif/arduino-esp32/blob/master/cores/esp32/HardwareSerial.h#L111-L205, I guess it is to avoid conflict with PSRAM pins (16/17) For point 2: ESP3D API changed at least more than 6 month ago https://esp3d.io/ESP3D/Version_3.X/documentation/commands/esp111/ for point 3 I need a screenshot of the output because I cannot duplicate with simple polling every 3s |
|
Thanks for the quick reply, here 2 screenshots and a copy from the terminal. I don't have this issue in the version before September 2024. |
|
What baudrate are you using ? |
|
Also may I know why you use Serial Port 2 - do you have same issue with Serial Port 0 ? |
|
I'm using 250K baud (previously tested 1M baud, which also used to work without any issues). If I switch back to last week's FW version, then the data corruption also disappears. I'm using Serial Port 2 to avoid the startup messages. |
|
you can use Serial 0 - to avoid startup message : https://esp3d.io/ESP3D/Version_3.X/documentation/faq I think your issue may be related to espressif/arduino-esp32#10117 |
Interesting, I could try that, but I'm not sure if that will work. Update: I did some testing, the data corruption indeed seems to be related to the serial baud rate. The error frequency goes up if I increase the baudrate. It's odd that for last week's status 1M baud works fine, while for this week's status 250K already causes errors. Unrelated: For the WebUI, if you send a command in the terminal, you could cancel Autoscroll so you can see the output of the command. |
I am now able to reproduce on Serial 0 with 1000000, I will have look if can be improved
The command are put in queue with polling commands so cancel autoscroll may not have the expected behavior, because command can be sent after others, and so you will see poilling commands answers before ,so finally you may not be able to see the terminal answer because autoscroll will be stopped too early, there is no link between in and out data |
|
Another odd thing I came accross: Same issue: |
So same serial issue I think - because using Using basic sample code on ESP32 : when on another ESP32 : Also using ESP3D on ESP32S3 I do not have issue even using 1000000, but on C3 I do not have any response at 1000000 I will need to dig in more on this it can be several reason because sample code is working fine on same C3 board ... orz |
|
The issue I mean with the "[ESP212]DATE:%ESP_DATETIME%" and "[ESP140]now" is NOT data corruption, but I get the complete wrong date and time. The year is obviously not correct, but all data is wrong. Both commands give the same year: 376671 I'm testing on a ESP32 WROOM dev module, if I go back to last weeks code, then things are working as expected. |
|
what internet time server did you set ? |
|
#define DEFAULT_TIME_SERVER1 "time.windows.com" I'm located in China. |
|
on my side : Try |
|
Here my log: ESP140]sync |
Ho boy - yes if I enable internet time it is wrong - I did not changed that for a while ... |
|
Yes, I can see that, no changes from last week to now on your side, so I expect my issue is in the layers underneath. espressif32 platform, or perhaps the Arduino or SSDP library. |
|
So far https://github.com/espressif/arduino-esp32/blob/master/libraries/ESP32/examples/Time/SimpleTime/SimpleTime.ino is working as expected : So my code may need some adjustment with latest release To be clear the previous code was using arduino esp32 2.0.8 (IDF 4.4.4) when now we are using 3.0.4 (IDF 5.1.4) - many things changed - so I may missed some changes Next week will be busy orz... |
|
That sketch works fine for me in the Arduino IDE. Also the following code give the correct year: In time_service.cpp it says: If I replace it like this: Then I get the correct date and time, including the correct timezone. If I then flash last week's version, and again flash the unmodified current version, then the problem is back, until I again replace the configTzTime line. Not sure if this makes sense, but that are my findings. |
|
I think I have fixed the time issue (4b01d89) - at least it works now on my side About Serial issue, after reading Code and new sample code I think I know what the issue is, I am actually surprised it did not happen before, part of the issue can be also the serial to usb adapter that can bring false error because it cannot handle 1M/2M baudrate, so during test it may be confusing when in real condition serial 2 serial it should not have error I have a some boards that work without issue at 2M baurate so I will use them as reference boards for fixing the issue. |
|
(4b01d89) doesn't solve my issue, I still get the wrong date and time "79289-01-07 01:43:5". Using this line does solve my problem: I don't understand why, because s1.c_str() seems to have the correct/same value. Note, here it sometimes seems like the problem is solved, but if I switch back to the previous version (from 1 week ago), and then go back to the current version, the problem is back. I attached my custom firmware that I used to go back to the old version via OTA, for ESP32 WROOM dev module. About the serial corruption issue. Perhaps there is a difference in how the hardware is configured to sample the serial data, or the clock setup is different. I don't know the details of ESP32, but I know that in STM32 there are a lot of registers that define how the incoming serial data is sampled. I do not use a USB serial adapter for testing, my setup is like this: |
|
I think I found the time server issue. Perhaps _time_zone_config should also be static. That works for me, and perfectly explains my odd findings. P.S. I don't understand what "t1" is doing, it doesn't seem to be defined anywhere. |
|
According https://github.com/espressif/esp-idf/blob/59e18382702b6986be3d3f55e9ac7763c1397cf7/components/lwip/apps/sntp/sntp.c#L227 t1 was for timezone string that moved to _time_zone_config and was not deleted - I will do some cleanup because seems still using by esp8266. Thank you for your finding - I will do some update About Serial - I use the onboard usb/serial to debug the issue that is all, as mentionned if ok with Serial USB adpter it will be Ok for Serial 2 Serial. About Serial corruption, the issue is data is accessed by multiple tasks at once and there is no protection on the serial buffer to have multiple access, it seems I missed it.... |
|
Great, thanks for looking into this. I will test the update and let you know my findings. |
|
I should be able to work on it tomorrow - today I was out all day |
|
Ok I did a full refactoring of Serial module - to simplify reading and avoid to break things, I have splitted esp8266/esp32 code my tests go through the PC USB / Serial USB Adaptor with a shield cable of 40cm - so if your printer serial / esp serial are direcly wired with shield cable it should be ok too as I am supposed to be in the worst situation FYR: Using USB Hub with 1 cable (no shield) and connecting my 40cm cable connected to ESP USB connector - I cannot reach 2M and have data corruption with 1M when 500 000 is ok (that one was actually the worst of the worst ) @rondlh please give a try to https://github.com/luc-github/ESP3D/tree/serial-Refactoring and let me know if you see some improvement |
|
The refactoring of Serial module update doesn't solve my serial data corruption issues. PIN: PB13 M42 P29 X_MIN_PIN protected |
|
What about 500000? |
500K is very similar to 1M baud, I cannot really notice a reduction in the corruption frequency. I see you also updated the NTP section, that is working fine now, even if I switch back to the old version, great! |
Well as you can see I can handle up to 2M so what I can imagine is : I will spend more time today on this to see if I can improve=> TBD
Yes I used independant task to avoid this, using new APi is more efficient
Yes I have put the server address as class variable so their pointers are not modified |
|
@rondlh I have backported the latest code for IDF 4.4.7/ esp32 core 2.0.17 on serial-Refactoring-idf-4.4.7 |
Thanks for your efforts. The fail at 921600 is quite strange and makes me think that the serial interface setup is just different. I will do another test with a USB serial converted and have a look at the signals on a scope to see if I can see a difference. |
|
That is why I have backported the code to IDF 4.4.7 only for ESP32 - to know if issue is related to IDF (which I suspect) or my code |
|
@rondlh Sorry, your feedback is with https://github.com/luc-github/ESP3D/tree/serial-Refactoring-idf-4.4.7 with env esp32_4_4_7 ? or with https://github.com/luc-github/ESP3D/tree/serial-Refactoring with env esp32dev ? Because |
|
Tested with https://github.com/luc-github/ESP3D/tree/serial-Refactoring I will test it again with: https://github.com/luc-github/ESP3D/tree/serial-Refactoring-idf-4.4.7 I assume I must build with: default_envs = esp32_4_4_7 The results with (https://github.com/luc-github/ESP3D/tree/serial-Refactoring-idf-4.4.7) are identical to the August ESP3D V3.0, no serial data corruption at 1M baud, and 921600 is working fine too. Conclusions: My serial data corruption issue seems not to be in your code, but in the API used. Note, tested with 2x BTT TFT35 V3.0, 1x BTT TFT35 V3.0.1, and 3 identical, but physically different ESP32 dev boards. Motherboard is 2x MKS Monster8 V1, 1x MKS Monster8 V2 |
|
@rondlh can you confirm that with https://github.com/luc-github/ESP3D/tree/serial-Refactoring-idf-4.4.7 (env esp32_4_4_7) the M43 incomplete reporting is also solved compare to old code ? Edit: Good news it seems 53.03.10+rc1 solve the serial issue |
Yes, confirmed, no lines are lost in the M43 report anymore, great job! |
|
PR #1048 is now merged - ESP32 has now 2 entries in Platformio
|
|
I will monitor the idf 5.3 / arduino 3.1 release to see if I can realign the version - but I found BR at 926100 seems not working with my esp32 when it is ok with IDF 4.4.7 / arduino 2.0.17 @rondlh Thank you for you time , your tests and your feedback was a tricky one |
Right, this at 926100 baud rate is a bit odd, especially because it's a typical ESP baud rate, it's another indication that something in the background has changed. Anyway, this is good progress, well done again! P.S. For some reason I don't have the option to close with comment here |
|
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
|
according : arduino-esp32/issues/9837 Need to test adds |
I noticed some big source changes recently in September 2024.
I found several issues:
I use serial port 2, with the default pins (RX=16, TX=17), this doesn't work anymore unless I specifically define the default pins
[ESP111]M117 doesn't reflect back the "M117" anymore, only the IP address.
I see data corruption in the terminal, typically at the end of a line. This happens quite frequently (about every 10-20 lines).
Expected behavior
ESP3D Firmware:
If you build with Arduino: Built with PlatformIO
Target Firmware:
Board used (please complete the following information):
Additional context
None
The text was updated successfully, but these errors were encountered: