- Welcome to Olimex Support Forum.
Olimex Support Forum
Recent posts
#1
ESP32 / Re: ESP32-PoE-ISO UART1 issue
Last post by LubOlimex - Today at 01:53:27 PMWell, read again slowly your last reply. Voila. That is how Schottky diodes work - it blocks current from travelling in reverse direction and also why the Schottky is fine on GPI36 (it has only one direction).
Just take my word for it - there is a hardware connection between ESP32 module pin #4 and UEXT pin #4 and it is visible in both the schematic and the PCB. It is not a straight wire, it has a diode on its way, and there is also pull-up resistor on the wire....
Listen, just do the following test, it is the easiest test, which people that test UART do first:
- Connect RX to TX via jumper wire like this:
- Open Arduino IDE, install the ESP32 support for Arduino and use this code:
- Download it to the board, refer to my settings (you'd have different COM port):
- Open serial monitor - you'd see pX every half a second; remove one side of the wire, message will change to BREAK, connect it back pX will resume again. Like here:
Now when it is clear that issue is not with the UART. You'd realize the problem is elsewhere, it is in the compatibility between MOD-RS485-ISO's firmware and the software libraries (ESPEasy, Modbus) you'd want to use.
Honestly, after analyzing and working on this for a few hours I don't think the default firmware of MOD-RS485-ISO would work with ESPEasy or Modbus - the main problem is that the board is designed for full duplex and ESPEasy and Modbus are made for half duplex; standard libraries like Modbus, ESPEasy, etc. expect either a dumb transceiver with controllable DE/RE or an auto-direction adapter. The firmware gives them neither in default pass mode. Also the firmware of MOD-RS485-ISO is like an alternative of ESPEasy and Modbus, it was made for people that want to use simple commands. There is no point of using MOD-RS485-ISO if you are going to use Modbus, that is what I am saying, since MOD-RS485-ISO has more hardware than required, and it is more expensive than a dumb transceiver. Like all possible ways forward are:
- Get another simpler RS485 transceiver and leave MOD-RS485-ISO for another task that doesn't require ESPEasy or Modbus;
- Use MOD-RS485-ISO without ESPEasy with its own commands, implement similar behavior to what ESPEasy does;
- Re-write parts of ESPEasy/Modbus so that it is compatible with MOD-RS485-ISO;
- Re-write the MOD-RS485-ISO firmware.
The software effort to modify ESPEasy or the firmware would be huge and would require a lot of knowledge.
That being written, take into account that the software of MOD-RS485-ISO is open source and sources are available to improve and study and modify.
Just take my word for it - there is a hardware connection between ESP32 module pin #4 and UEXT pin #4 and it is visible in both the schematic and the PCB. It is not a straight wire, it has a diode on its way, and there is also pull-up resistor on the wire....
Listen, just do the following test, it is the easiest test, which people that test UART do first:
- Connect RX to TX via jumper wire like this:
- Open Arduino IDE, install the ESP32 support for Arduino and use this code:
Code Select
uint32_t c = 0;
void setup() {
Serial.begin(115200);
Serial2.begin(115200, SERIAL_8N1, 36, 4);
}
void loop() {
Serial2.printf("P%lu\n", c++);
delay(500);
if (Serial2.available()) {
Serial.println(Serial2.readString());
} else {
Serial.println("BREAK");
}
}- Download it to the board, refer to my settings (you'd have different COM port):
- Open serial monitor - you'd see pX every half a second; remove one side of the wire, message will change to BREAK, connect it back pX will resume again. Like here:
Now when it is clear that issue is not with the UART. You'd realize the problem is elsewhere, it is in the compatibility between MOD-RS485-ISO's firmware and the software libraries (ESPEasy, Modbus) you'd want to use.
Honestly, after analyzing and working on this for a few hours I don't think the default firmware of MOD-RS485-ISO would work with ESPEasy or Modbus - the main problem is that the board is designed for full duplex and ESPEasy and Modbus are made for half duplex; standard libraries like Modbus, ESPEasy, etc. expect either a dumb transceiver with controllable DE/RE or an auto-direction adapter. The firmware gives them neither in default pass mode. Also the firmware of MOD-RS485-ISO is like an alternative of ESPEasy and Modbus, it was made for people that want to use simple commands. There is no point of using MOD-RS485-ISO if you are going to use Modbus, that is what I am saying, since MOD-RS485-ISO has more hardware than required, and it is more expensive than a dumb transceiver. Like all possible ways forward are:
- Get another simpler RS485 transceiver and leave MOD-RS485-ISO for another task that doesn't require ESPEasy or Modbus;
- Use MOD-RS485-ISO without ESPEasy with its own commands, implement similar behavior to what ESPEasy does;
- Re-write parts of ESPEasy/Modbus so that it is compatible with MOD-RS485-ISO;
- Re-write the MOD-RS485-ISO firmware.
The software effort to modify ESPEasy or the firmware would be huge and would require a lot of knowledge.
That being written, take into account that the software of MOD-RS485-ISO is open source and sources are available to improve and study and modify.
#2
ESP32 / Re: ESP32-PoE-ISO UART1 issue
Last post by bartgrefte - Today at 12:18:34 PMAs for the schottky diode, I did a continuitytest over the diode, beep in one direction, no beep other way round. No beep between UEXT pin 4 and GPI(O)36 pin on the side of the board, in either direction.
#3
ESP32 / Re: ESP32-PoE-ISO UART1 issue
Last post by bartgrefte - Today at 10:51:12 AM"GPIO36 can only be input which is fine for RXD"
I am aware of that, GPI(O)36 is selected for Rx1 (HW Serial1 in ESPEasy) and 4 for Tx1 and ESPEasy is also aware 36 is input only (there's an arrow next to it indicating input only, can't even select 36 as Tx). But that does not explain why a continuity test does work between the GPI(O)36 pin on the side of the pcb and the ESP32, but not between UEXT pin 4 (GPI(O)36/Rx1) and both the other GPI(O)36 as well as the ESP32, doesn't it?
"I have no idea where are you looking at the schematic but the connection between GPI36 and the main module is visible. Here is an excerpt with wire path circled"
I am looking at https://github.com/OLIMEX/ESP32-POE-ISO/blob/master/HARDWARE/ESP32-PoE-ISO-Rev.M/ESP32-PoE-ISO_Rev_M.kicad_pcb in KiCad, where I followed the trace and couldn't find a connection to the solderpad of UEXT pin4. That, plus the failed continuity tests and data being send but not received, made me think UEXT pin4 isn't connected to anything.
"I believe the issue is somewhere in the pass part of the firmware, which is probably not a real problem for you, since you can use the I2C pins, but can be a problem for somebody that doesn't have the free pins."
Well, I was planning on using the Rx/Tx pins since I2C will be used by other things.
"Meanwhile, I will try to create simple Modbus demo for Arduino IDE to demonstrate using Modbus between two ESP32-POE-ISO boards and two MOD-RS485-ISO"
I have been using ESPEasy for that, specifically plugin https://espeasy.readthedocs.io/en/latest/Plugin/P078.html , but instead I also tried the serial server and then ModBus Poll on Windows through a virtual comport. Again, data is being send, nothing received.
I am aware of that, GPI(O)36 is selected for Rx1 (HW Serial1 in ESPEasy) and 4 for Tx1 and ESPEasy is also aware 36 is input only (there's an arrow next to it indicating input only, can't even select 36 as Tx). But that does not explain why a continuity test does work between the GPI(O)36 pin on the side of the pcb and the ESP32, but not between UEXT pin 4 (GPI(O)36/Rx1) and both the other GPI(O)36 as well as the ESP32, doesn't it?
"I have no idea where are you looking at the schematic but the connection between GPI36 and the main module is visible. Here is an excerpt with wire path circled"
I am looking at https://github.com/OLIMEX/ESP32-POE-ISO/blob/master/HARDWARE/ESP32-PoE-ISO-Rev.M/ESP32-PoE-ISO_Rev_M.kicad_pcb in KiCad, where I followed the trace and couldn't find a connection to the solderpad of UEXT pin4. That, plus the failed continuity tests and data being send but not received, made me think UEXT pin4 isn't connected to anything.
"I believe the issue is somewhere in the pass part of the firmware, which is probably not a real problem for you, since you can use the I2C pins, but can be a problem for somebody that doesn't have the free pins."
Well, I was planning on using the Rx/Tx pins since I2C will be used by other things.
"Meanwhile, I will try to create simple Modbus demo for Arduino IDE to demonstrate using Modbus between two ESP32-POE-ISO boards and two MOD-RS485-ISO"
I have been using ESPEasy for that, specifically plugin https://espeasy.readthedocs.io/en/latest/Plugin/P078.html , but instead I also tried the serial server and then ModBus Poll on Windows through a virtual comport. Again, data is being send, nothing received.
#4
ESP32 / Re: ESP32-PoE-ISO UART1 issue
Last post by LubOlimex - Today at 08:19:53 AMNo, but I can confirm the opposite. Let me explain why you are measuring wrong:
1. Notice how we named GPIO36 as GPI36. This is not naming error. GPIO36 can only be input which is fine for RXD. This is the way the ESP32 chip and modules were designed, some pins can only be inputs. So GPIO36 actually can't be output or serve for TXD.
2. There is D4 SCHOTTKY diode to prevent parasitic powering over the RXD pin and act as protection.
3. I have no idea where are you looking at the schematic but the connection between GPI36 and the main module is visible. Here is an excerpt with wire path circled:
I believe the issue is somewhere in the pass part of the firmware, which is probably not a real problem for you, since you can use the I2C pins, but can be a problem for somebody that doesn't have the free pins.
Meanwhile, I will try to create simple Modbus demo for Arduino IDE to demonstrate using Modbus between two ESP32-POE-ISO boards and two MOD-RS485-ISO.
1. Notice how we named GPIO36 as GPI36. This is not naming error. GPIO36 can only be input which is fine for RXD. This is the way the ESP32 chip and modules were designed, some pins can only be inputs. So GPIO36 actually can't be output or serve for TXD.
2. There is D4 SCHOTTKY diode to prevent parasitic powering over the RXD pin and act as protection.
3. I have no idea where are you looking at the schematic but the connection between GPI36 and the main module is visible. Here is an excerpt with wire path circled:
I believe the issue is somewhere in the pass part of the firmware, which is probably not a real problem for you, since you can use the I2C pins, but can be a problem for somebody that doesn't have the free pins.
Meanwhile, I will try to create simple Modbus demo for Arduino IDE to demonstrate using Modbus between two ESP32-POE-ISO boards and two MOD-RS485-ISO.
#5
ESP32 / Re: ESP32-PoE-ISO UART1 issue
Last post by bartgrefte - May 20, 2026, 07:16:33 PMAh, there did my message go, a notification that it was split off to a separate topic would've helped 
Well, why does the MOD-RS485-ISO manual not indicate the LED's should be on in passthrough mode? It's only listed on the wiki, the LED's where off, since they (according to the schematic in the manual) are connected to the ICSP-connector I thought the LED's being off was normal.
Turns out the MOD-RS485-ISO wasn't set to factory default before shipping, a reset solved that, but not the actual problem.
Then I took my multimeter and checked if the RS485-side was actually active (voltage measurements), no problem there.
Just now I figured out why it is not working: According to the continuity mode of my multimeter, the UEXT-pin for GPIO36/U1RXD isn't connected to anything, which the schematic (rev M) seems to confirm. While both the GPIO4/U1TXD on UEXT and the side of the board and GPIO36 on the side of the board are actually connected to the ESP32.
Can you confirm that the schematic does not contain a connection between UEXT-pin GPIO36/U1RXD and the other GPIO36 and the ESP32?
Well, why does the MOD-RS485-ISO manual not indicate the LED's should be on in passthrough mode? It's only listed on the wiki, the LED's where off, since they (according to the schematic in the manual) are connected to the ICSP-connector I thought the LED's being off was normal.
Turns out the MOD-RS485-ISO wasn't set to factory default before shipping, a reset solved that, but not the actual problem.
Then I took my multimeter and checked if the RS485-side was actually active (voltage measurements), no problem there.
Just now I figured out why it is not working: According to the continuity mode of my multimeter, the UEXT-pin for GPIO36/U1RXD isn't connected to anything, which the schematic (rev M) seems to confirm. While both the GPIO4/U1TXD on UEXT and the side of the board and GPIO36 on the side of the board are actually connected to the ESP32.
Can you confirm that the schematic does not contain a connection between UEXT-pin GPIO36/U1RXD and the other GPIO36 and the ESP32?
#6
ESP32 / Re: ESP32-PoE-ISO UART1 issue
Last post by LubOlimex - May 19, 2026, 08:26:23 AMThe way to test UART of ESP32-PoE-ISO is pretty simple, connect RX and TX (with a jumper wire with female-female connectors) and open terminal and type something and see if there is echo (e.g. what you type gets printed back). If there is echo - the UART is fine and the issue is somewhere else.
I think the issue is just wrongfully using MOD-RS485-ISO, it is not a basic bare convertor. It has a main microcontroller and own firmware, and while it can be used with Modbus or similar, it is meant to be used with own firmware and commands.
I think the issue is just wrongfully using MOD-RS485-ISO, it is not a basic bare convertor. It has a main microcontroller and own firmware, and while it can be used with Modbus or similar, it is meant to be used with own firmware and commands.
#7
A64 / A64-OLinuXino-2Ge16G-IND: U-Bo...
Last post by Brati - May 18, 2026, 04:52:36 PMI am developing a Yocto 5.0 (Scarthgap) Linux image for the A64-OLinuXino-2Ge16G-IND board and have encountered a critical issue with warm reboot that I have been unable to resolve.
Issue:
The board hangs on every reboot (warm reset and cold reset) after the following boot log line:
INFO: BL31: Preparing for EL3 exit to normal world
INFO: Entry point address = 0x4a000000
INFO: SPSR = 0x3c9
[HANG - no U-Boot output]
First cold power-on always works correctly. The hang occurs every time after any reboot command.
Setup:
- Board: A64-OLinuXino-2Ge16G-IND
- U-Boot: 2024.01 (mainline, from Yocto Scarthgap / poky)
- TF-A: 2.10.4 with SUNXI_PSCI_USE_NATIVE=1 SUNXI_PSCI_USE_SCPI=1
- Crust SCP: v0.6.0 (a64-olinuxino_defconfig)
- Kernel: Linux 6.6.85
- Boot device: SD card (mmcblk0)
What I have tried:
- Added Crust SCP firmware (scp.bin embedded in U-Boot SPL)
- Added R_WDOG fix for A64 in reset_cpu() in board.c
- Added PLL6 lock timeout in clock_init_safe() in clock_sun6i.c
- TF-A rebuilt with LOG_LEVEL=40 - confirmed BL31 completes successfully and hands off to U-Boot at 0x4a000000
- U-Boot freezes before printing a single character
The hang is confirmed to be between BL31 exit and U-Boot's first UART output.
Question:
Can anyone please share which U-Boot version and if any specific patches you use in your Olimage builds for the A64-OLinuXino to make reboot work correctly?
Any guidance would be greatly appreciated.
Best regards,
Bratiranjan Acharya
bratiranjan12@gmail.com
Issue:
The board hangs on every reboot (warm reset and cold reset) after the following boot log line:
INFO: BL31: Preparing for EL3 exit to normal world
INFO: Entry point address = 0x4a000000
INFO: SPSR = 0x3c9
[HANG - no U-Boot output]
First cold power-on always works correctly. The hang occurs every time after any reboot command.
Setup:
- Board: A64-OLinuXino-2Ge16G-IND
- U-Boot: 2024.01 (mainline, from Yocto Scarthgap / poky)
- TF-A: 2.10.4 with SUNXI_PSCI_USE_NATIVE=1 SUNXI_PSCI_USE_SCPI=1
- Crust SCP: v0.6.0 (a64-olinuxino_defconfig)
- Kernel: Linux 6.6.85
- Boot device: SD card (mmcblk0)
What I have tried:
- Added Crust SCP firmware (scp.bin embedded in U-Boot SPL)
- Added R_WDOG fix for A64 in reset_cpu() in board.c
- Added PLL6 lock timeout in clock_init_safe() in clock_sun6i.c
- TF-A rebuilt with LOG_LEVEL=40 - confirmed BL31 completes successfully and hands off to U-Boot at 0x4a000000
- U-Boot freezes before printing a single character
The hang is confirmed to be between BL31 exit and U-Boot's first UART output.
Question:
Can anyone please share which U-Boot version and if any specific patches you use in your Olimage builds for the A64-OLinuXino to make reboot work correctly?
Any guidance would be greatly appreciated.
Best regards,
Bratiranjan Acharya
bratiranjan12@gmail.com
#8
New Product Ideas / Re: can a lime 2 or pico 2 xxl...
Last post by LubOlimex - May 18, 2026, 02:50:40 PMAll three of the boards that you mentioned can run completely open source software. Yet there is major difference between the Raspberry Pi product and Olimex products - Raspberry Pi Zero W is not open-hardware, while Olimex provides files used to manufacture their products, when it comes to A20-OLinuXino-LIME2 and PICO2-XXL. These are open-hardware products.
About the software - the official Linux image provided by Olimex for A20-OLinuXino-LIME2 is truly open-source software, and contains no binary blobs. This is mentioned in the Olimage guide here:
https://github.com/OLIMEX/OLINUXINO/blob/master/DOCUMENTS/OLIMAGE/Olimage-guide.pdf
PICO2-XXL doesn't come with own software, the software Olimex provides for PICO2-XXL is based on the RPi SDK, so expect similar software as what Raspberry Pi Zero W uses.
About the software - the official Linux image provided by Olimex for A20-OLinuXino-LIME2 is truly open-source software, and contains no binary blobs. This is mentioned in the Olimage guide here:
https://github.com/OLIMEX/OLINUXINO/blob/master/DOCUMENTS/OLIMAGE/Olimage-guide.pdf
PICO2-XXL doesn't come with own software, the software Olimex provides for PICO2-XXL is based on the RPi SDK, so expect similar software as what Raspberry Pi Zero W uses.
#9
ESP32 / ESP32-PoE-ISO UART1 issue
Last post by bartgrefte - May 17, 2026, 06:54:41 PMMy apologies for the kick.
@ninousf and @_AndreaS_ , did you end up solving it? Running the 16MB build of ESPEasy here, I'm trying to use the MOD-RS485-ISO with HW serial1 on GPIO's 36 (Rx) and 4 (Tx).
So far no luck.
@ninousf and @_AndreaS_ , did you end up solving it? Running the 16MB build of ESPEasy here, I'm trying to use the MOD-RS485-ISO with HW serial1 on GPIO's 36 (Rx) and 4 (Tx).
So far no luck.
#10
New Product Ideas / can a lime 2 or pico 2 xxl run...
Last post by oeren - May 17, 2026, 05:13:02 PMhttps://www.crowdsupply.com/open-tools/open-printer
In the following I am assuming that the software which is running the open printer is free software.
Unfortunately the open printer people decided to go with a rpi zero w. The rpi zero w requires non free software in order to work. In result free software people do not want to use the open printer. On the other hand should it be possible to replace the rpi zero w with a computer able to run entirely on free software the open printer would get relevant for free software people.
Both lime 2 and pico 2 xxl can run entirely on free software correct? If so can I get to know if the lime 2 and pico 2 xxl are candidates for replacing a rpi zero w?
Please do not provide answers if you are not familiar with what free software is in the context of the free software foundation. Thank you.
In the following I am assuming that the software which is running the open printer is free software.
Unfortunately the open printer people decided to go with a rpi zero w. The rpi zero w requires non free software in order to work. In result free software people do not want to use the open printer. On the other hand should it be possible to replace the rpi zero w with a computer able to run entirely on free software the open printer would get relevant for free software people.
Both lime 2 and pico 2 xxl can run entirely on free software correct? If so can I get to know if the lime 2 and pico 2 xxl are candidates for replacing a rpi zero w?
Please do not provide answers if you are not familiar with what free software is in the context of the free software foundation. Thank you.