Closed tabunslonopotamov closed 8 months ago
That specific hardware configuration is currently not supported by the Espressif IDF 5.1 framework used, but that's the first version of the framework to add support for the jl1101 phy. The currently available options in ESPEasy is all that's technically possible to use. It can be disappointing that some manufacturers, by thinking to implement something 'smart' to distinguish from the crowd, as a result create non-standard/unsupported hardware 😞
Have they provided information by which frameworks/versions their board is supported?
Found some more info. It seems that this board should actually work with the default GPIO17_INV signal for Clock, but the phy address has to be set to 0.
I don't think it is even possible to select non-inverted GPIO-17 as those options are just an enum in the Arduino/ESP-IDF code. For RMII based Ethernet boards it is quite important to have the phy address set correctly. (less important for some SPI based Ethernet chips like the W5500)
Found some more info. It seems that this board should actually work with the default GPIO17_INV signal for Clock, but the phy address has to be set to 0.
Log espeasy with the setting:
340: ETH PHY Type: JL1101 PHY Addr: 0 Eth Clock mode: 50MHz APLL Inverted Output on GPIO17 MDC: 23 MIO: 18 PWR: 0 341: ETH power ON 768: ETH : Failed to initialize ETH
Found some more info. It seems that this board should actually work with the default GPIO17_INV signal for Clock, but the phy address has to be set to 0.
In that discussion thread, Jason2866 is the original developer and seller of the Dingtian series of boards
and there they talk about clk_mode: GPIO17_OUT , no inverted.
Well, I do know Jason2866, so will ask him about it.
PHY_JL1101_compatible_RTL8201F.pdf The jl1101 is more or less a clone of the rtl8201. Modell ID register values are different. I added a driver for in Tasmota IDF 4.4 and IDF 5.1. The needed changes to support are done in Tasmota Arduino Core 2.0.12 until 2.0.14 and in alpha 3.0.0 builds. Look for how it works for the rtl8201 and simply replace the name with jl1101. Tasmota Ethernet driver where it is used / available https://github.com/arendst/Tasmota/blob/development/tasmota/tasmota_xdrv_driver/xdrv_82_esp32_ethernet.ino With latest core 3.0.0 alpha build ETH address auto detection is supported. Btw. i am not related to Dingtian nor i do sell anything. Don't even have such a board.
Btw. i am not related to Dingtian nor i do sell anything. Don't even have such a board.
I apologize for the misinformation. The seller's representative on WhatApp is also named Jason and he gave links to your github claiming that this is a patch made for their product.
Yes, the patch or better adding a fully working IDF driver for the jl1101 was done to support the Dingitian relay board fully with Tasmota.
Is there anything I can do to properly initialize Ethernet on a board with espeasy firmware? Building the latest version from github is not working properly.
I will have a look at the code, but I don't have such a board so I can't really test it myself.
Which exact build did you try yourself? N.B. the ESP32-xx builds with LittleFS are using the latest ESP-IDF 5.1 code
gpio define and ESP-IDF gpio test demo source code https://github.com/dtlzp/relay_dev_demo JL1101(compatiable with RTL8201F, only chip id is different)
https://github.com/dtlzp/relay_arduino_demo
this is JL1101 datasheet https://github.com/dtlzp/relay_dev_demo/blob/main/datasheet/PHY_JL1101_compatible_RTL8201F.pdf
this ESP-IDF patch for JL1101 https://github.com/dtlzp/relay_dev_demo/blob/main/esp-idf-dt-patch/components/esp_eth/src/esp_eth_phy_jl1101.c
https://github.com/dtlzp/relay_dev_demo/blob/main/esp-idf-dt-patch/components/esp_eth/src/esp_eth_phy_jl1101.c the "esp_eth_phy_jl1101.c" the only different with "esp_eth_phy_rtl8201.c" is chip ID
JL1101 ID: id1.oui_msb = 0x937C id2.oui_lsb = 0x10 id2.vendor_model = 0x2
@dtlzp I have wrote you a email, regarding support of jl1101 in upcoming Tasmota Arduino Core 3.0.0 (used by ESPEasy too).
I will have a look at the code, but I don't have such a board so I can't really test it myself.
Which exact build did you try yourself? N.B. the ESP32-xx builds with LittleFS are using the latest ESP-IDF 5.1 code
This binary espeasy firmware Build:⋄ 20240229 - Mega32 System Libraries:⋄ ESP32 SDK 5.1.2.240206 Binary Filename: ESP_Easy_mega_20240229_custom_ESP32_4M316k_LittleFS_ETH
not working with setting
2225: ETH PHY Type: JL1101 PHY Addr: -1 Eth Clock mode: 50MHz APLL Inverted Output on GPIO17 MDC: 18 MIO: 23 PWR: 0 2225: ETH power ON 2626: ethResetGPIOpins() 2732: ETH : Failed to initialize ETH
And can you set the GPIO-0 pin on the hardware tab to "output high"? Then reboot.
If that doesn't work, try to set it to "output low" on the Hardware tab, as it is also marked as a RST pin See: https://github.com/dtlzp/relay_dev_demo/blob/main/gpio_pinout/8ch.png
And can you set the GPIO-0 pin on the hardware tab to "output high"? Then reboot.
If that doesn't work, try to set it to "output low" on the Hardware tab, as it is also marked as a RST pin See: https://github.com/dtlzp/relay_dev_demo/blob/main/gpio_pinout/8ch.png
Both choices failed to successfully initialize ethernet.
Powering on phy works correctly. This is confirmed by enable link indicator on network switch when booting this boars.
On the board itself the green diode also lights up and blinks in rhythm with the received packets.
ESP-IDF v5.1 modify rtl8201 driver to JL1101 example
code link: https://github.com/espressif/esp-idf/blob/release/v5.1/components/esp_eth/src/esp_eth_phy_rtl8201.c
JL1101 ID: id1.oui_msb = 0x937C id2.oui_lsb = 0x10 id2.vendor_model = 0x2
// modify rtl8201_init
static esp_err_t rtl8201_init(esp_eth_phy_t *phy)
{
esp_err_t ret = ESP_OK;
phy_802_3_t *phy_802_3 = esp_eth_phy_into_phy_802_3(phy);
/* Basic PHY init */
ESP_GOTO_ON_ERROR(esp_eth_phy_802_3_basic_phy_init(phy_802_3), err, TAG, "failed to init PHY");
/* Check PHY ID */
uint32_t oui;
uint8_t model;
ESP_GOTO_ON_ERROR(esp_eth_phy_802_3_read_oui(phy_802_3, &oui), err, TAG, "read OUI failed");
ESP_GOTO_ON_ERROR(esp_eth_phy_802_3_read_manufac_info(phy_802_3, &model, NULL), err, TAG, "read manufacturer's info failed");
//ESP_GOTO_ON_FALSE(oui == 0x732 && model == 0x1, ESP_FAIL, err, TAG, "wrong chip ID");
ESP_GOTO_ON_FALSE(oui == 0x24DF10 && model == 0x2, ESP_FAIL, err, TAG, "wrong chip ID");/* (0x0x937C << 6) | 0x10) == 0x24DF10 */
return ESP_OK;
err:
return ret;
}
PHY_JL1101_compatible_RTL8201F.pdf The jl1101 is more or less a clone of the rtl8201. Modell ID register values are different. I added a driver for in Tasmota IDF 4.4 and IDF 5.1. The needed changes to support are done in Tasmota Arduino Core 2.0.12 until 2.0.14 and in alpha 3.0.0 builds. Look for how it works for the rtl8201 and simply replace the name with jl1101. Tasmota Ethernet driver where it is used / available https://github.com/arendst/Tasmota/blob/development/tasmota/tasmota_xdrv_driver/xdrv_82_esp32_ethernet.ino With latest core 3.0.0 alpha build ETH address auto detection is supported. Btw. i am not related to Dingtian nor i do sell anything. Don't even have such a board.
Mode in this tasmota driver ETH_CLOCK_GPIO17_OUT no mention of inversion
@dtlzp
For your information, we're using this cherry-picked branch of ESP-IDF: https://github.com/tasmota/esp-idf/blob/release/v5.1/components/esp_eth/src/esp_eth_phy_jl1101.c @Jason2866 does maintain this branch and also a special cherry picked branch of espressif/Arduino so we are able to use IDF 5.1 and the latest Arduino code as a PlatformIO package.
This is needed as there is no official PlatformIO package for the latest ESP-IDF/Arduino code and we need to support the latest Espressif SoC's and Ethernet chips out there (e.g. SPI connected Ethernet)
Anyway, at first glance I don't see anything wrong in the code added by @Jason2866
@tabunslonopotamov
Can you make the following change in platformio_core_defs.ini
in [core_esp32_IDF5_1__3_0_0]
platform_packages = framework-arduinoespressif32 @ https://github.com/Jason2866/esp32-arduino-lib-builder/releases/download/2151/framework-arduinoespressif32-release_v5.1-1a0b6e0.zip
This wil use the latest PlatformIO framework package @Jason2866 built last night.
platform_packages = framework-arduinoespressif32 @ https://github.com/Jason2866/esp32-arduino-lib-builder/releases/download/2151/framework-arduinoespressif32-release_v5.1-1a0b6e0.zip
Thank you. The firmware compiled with this version of idf successfully initialized Ethernet.
Parameters in ESPEasyGPIO → Ethernet PHY type: JL1101 Ethernet PHY Address: 0
Ethernet MDC/CS pin: web: GPIO-23 GPIO ← Ethernet MDIO/IRQ pin: GPIO-18 GPIO → Ethernet Power/RST pin: GPIO-0 Ethernet Clock: 50MHz APLL Inverted Output on GPIO-17
Can you also check whether it does still work if you unplug the Ethernet connector and replug it?
Can you also check whether it does still work if you unplug the Ethernet connector and replug it?
after disconnecting ethernet plug , the board did not ping to any of the 2x IP addresses (WiFi and Ethernet) for 5-10 seconds. After turning the rj45 connector back on ping to Ethernet IP was restored instantly, less than 1 second. ( Ping to WiFi IP immediately lost )
WiFi probably had to perform a full scan, so that may take upto 6 sec. Sounds like expected behavior.
yes Tasmota already support JL1101, i have tested is ok
From: TD-er Date: 2024-03-06 15:42 To: letscontrolit/ESPEasy CC: Dingtian; Mention Subject: Re: [letscontrolit/ESPEasy] [FR] Please add Ethernet clock mode - GPIO17 without inverted. (Issue #4998) @dtlzp For your information, we're using this cherry-picked branch of ESP-IDF: https://github.com/tasmota/esp-idf/blob/release/v5.1/components/esp_eth/src/esp_eth_phy_jl1101.c @Jason2866 does maintain this branch and also a special cherry picked branch of espressif/Arduino so we are able to use IDF 5.1 and the latest Arduino code as a PlatformIO package. This is needed as there is no official PlatformIO package for the latest ESP-IDF/Arduino code and we need to support the latest Espressif SoC's and Ethernet chips out there (e.g. SPI connected Ethernet) Anyway, at first glance I don't see anything wrong in the code added by @Jason2866 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>
If you perform the same unplug/plug test as before within 5 minutes from each test then the WiFi connection will be way more quickly. If you have checked the checkbox "Use Last Connected AP from RTC" on the Tools->Advanced page , the WiFi reconnect may be near instant (< 1 sec)
If you perform the same unplug/plug test as before within 5 minutes from each test then the WiFi connection will be way more quickly. If you have checked the checkbox "Use Last Connected AP from RTC" on the Tools->Advanced page , the WiFi reconnect may be near instant (< 1 sec)
thanks for the tip Is it possible to make both IPs available all the time?
Nope, currently there is no support for 'routing' between interfaces.
This might be added later as there is support in ESP-IDF for multiple Ethernet interfaces (mainly SPI with interface) But right now the support for multiple interfaces and IP routing in Arduino is "minimal" to put it mildly.
As soon as the pending pull request in the Arduino code to redesign the complete network code is complete, I will also do a large overhaul in the ESPEasy network code as it has grown (mainly the WiFi code) to a big kludge of way too complex code due to working around undocumented bugs in the WiFi code. (most of it related to ESP8266)
Making both IPs reachable does not mean routing. With Tasmota the device is reachable via the WiFi and the Ethernet IP at the same time when both are connected.
I have made it deliberately a XOR state in ESPEasy as in my opinion it often only causes issues if both interfaces are in the same subnet. When the PR for network rewrite is done, I will make it configurable which interface is enabled, which is the preferred one to act as a gateway, etc. And also add some predefined order of states when only a single interface should be active. (e.g. when Ethernet is not plugged in, consider WiFi as fallback)
I have made it deliberately a XOR state in ESPEasy as in my opinion it often only causes issues if both interfaces are in the same subnet. When the PR for network rewrite is done, I will make it configurable which interface is enabled, which is the preferred one to act as a gateway, etc. And also add some predefined order of states when only a single interface should be active. (e.g. when Ethernet is not plugged in, consider WiFi as fallback)
We consider WiFi as a backup. But I would like to be able to monitor that the backup route is “alive” and available before the Ethernet fails.
Like I said, as soon as the major rewrite in Arduino code is done, I will do a major cleanup in the ESPEasy code to change all network-related code. It would be a waste of time and effort to do it earlier as the upcoming changes in the Arduino network related code are so significant anything done now will have to be redone then.
I estimate it may take me like 3 full weeks to implement all the network code.
Podskazhite pozhaluysta, kakoye v itoge resheniye bylo prinyato v osnovnoy vetke?
Dolzhno li pri rabote cherez Ethernet rabotat' inache, chem cherez WiFi?
Pereklyuchilsya na Ethernet i obnaruzhil, chto problema sokhranyayetsya.
(khotya i propala li po WiFi tozhe dostoverno vyyasnit' ne udalos').
Sam port Ethernet i blizhayshiy marshrutizator ne otklyuchayutsya, u menya propadayet svyaz' s serverom mqtt i vse podvisayet na neskol'ko sekund.
Please tell me what decision was ultimately made in the main branch?
Should it work differently when running over Ethernet than over WiFi?
Switched to Ethernet and found the problem persisted.
(although it was also not possible to reliably find out whether it disappeared via WiFi).
The Ethernet port itself and the nearest router do not turn off, my connection to the mqtt server is lost and everything freezes for a few seconds.
In a recent testbuild I made quite a lot of changes regarding disconnect/reconnect to MQTT controllers as this was indeed causing a lot of delays.
See this test build: https://td-er.nl/ESPEasy/latest/
I use espeasy with this version of esp32 controller from Dingtian. https://www.dingtian-tech.com/en_us/relay8.html
previous versions of the board used ethernet phy lan8720 and worked correctly. In new revisions of the board, phy jl1101 is used and does not start ethernet correctly. The seller of the board writes that you need to use Ethernet Clock on GPIO17 without inversion.
I tried to figure it out and make changes to the espeasy code myself, but none of my actions led to the ethernet module starting to initialize normally. phy itself is in an active state (power pin active)
help me please