- Welcome to Olimex Support Forum.
Olimex Support Forum
Recent posts
#1
A64 / Re: Battery wont charge
Last post by LubOlimex - Today at 11:25:19 AMAnd you have two A64 boards behaving exactly the same when it comes to the charging?
Did you measure the input voltage at the boards when the battery is connected, is it 5V exactly? The power is applied to the power jack right?
Did you measure the voltages of batteries to see if the voltage reported by the Linux is the same as the voltage measured by voltage meter?
I did some test with A64 board (found revision G to be exact) and 3000mAh battery and it works fine:
You see my battery is nearing 4.1V which is higher the point your stopped, I use the same revision board and the same software. Which excludes a lot of of the things that might have went wrong.
The thing is I can't remember ever seen charging circuit failed in such a way that would charge batteries only half-way. Chances of board failed in such a way are slim, let alone two boards with the same issue (unless both boards got damaged in the same way, e.g. if you connected a battery with reverse polarity connector, but then again they won't charge at all, not just charge up to 44% or 66%). I would suspect power supply somehow can't deliver enough current and maintain voltage or somehow failed batteries. My guesses:
1. Bad external PSU / cable / barrel connector / input voltage at board
Measure 5V directly on the A64 board while battery is connected. PSU display alone is not enough.
2. Battery/protection/connector issue
Especially since both A64 boards behave the same. Test with new Li-Po. Double check Li-Po connectors.
3. Maybe try to re-write the base image and use the default config settings, remember to once reboot the software to load optimal defaults. Maybe try to increase the charge current:
Did you measure the input voltage at the boards when the battery is connected, is it 5V exactly? The power is applied to the power jack right?
Did you measure the voltages of batteries to see if the voltage reported by the Linux is the same as the voltage measured by voltage meter?
I did some test with A64 board (found revision G to be exact) and 3000mAh battery and it works fine:
Quoteroot@a64-olinuxino:~# cat /sys/class/power_supply/axp20x-battery/status
cat /sys/class/power_supply/axp20x-battery/voltage_now
cat /sys/class/power_supply/axp20x-battery/current_now
cat /sys/class/power_supply/axp20x-battery/constant_charge_current
cat /sys/class/power_supply/axp813-ac/input_current_limit
Charging
4097000
1394000
1200000
1500000
root@a64-olinuxino:~#
You see my battery is nearing 4.1V which is higher the point your stopped, I use the same revision board and the same software. Which excludes a lot of of the things that might have went wrong.
The thing is I can't remember ever seen charging circuit failed in such a way that would charge batteries only half-way. Chances of board failed in such a way are slim, let alone two boards with the same issue (unless both boards got damaged in the same way, e.g. if you connected a battery with reverse polarity connector, but then again they won't charge at all, not just charge up to 44% or 66%). I would suspect power supply somehow can't deliver enough current and maintain voltage or somehow failed batteries. My guesses:
1. Bad external PSU / cable / barrel connector / input voltage at board
Measure 5V directly on the A64 board while battery is connected. PSU display alone is not enough.
2. Battery/protection/connector issue
Especially since both A64 boards behave the same. Test with new Li-Po. Double check Li-Po connectors.
3. Maybe try to re-write the base image and use the default config settings, remember to once reboot the software to load optimal defaults. Maybe try to increase the charge current:
Quoteecho 1200000 > /sys/class/power_supply/axp20x-battery/constant_charge_current
cat /sys/class/power_supply/axp20x-battery/current_now
#2
A64 / Re: Battery wont charge
Last post by mauricio - June 24, 2026, 04:14:22 PMHello.
Capacity of first battery is 1000mAh. Second one is 3100mAh.
First one charges up to 66% at A64, 100% at A20. Second one 44% at A64, not tested on A20.
Yes, I did poweroff on A64 and look for current, regulated power says 0.001A.
When A64 is on, power or current doesn't go up. It stays ~330mA.
Thanks.
Capacity of first battery is 1000mAh. Second one is 3100mAh.
First one charges up to 66% at A64, 100% at A20. Second one 44% at A64, not tested on A20.
Yes, I did poweroff on A64 and look for current, regulated power says 0.001A.
When A64 is on, power or current doesn't go up. It stays ~330mA.
Thanks.
#3
A64 / Re: Battery wont charge
Last post by LubOlimex - June 24, 2026, 11:47:38 AMWhat is the capacity of the battery?
Is this the exact same battery used with A20-OLinuXino-MICRO (where it charges fully)?
Since you use external power supply, you can easily check if the battery is charging, check the power draw without the battery, and check again with the battery. If the battery is charging the current draw should be considerably higher.
Is this the exact same battery used with A20-OLinuXino-MICRO (where it charges fully)?
Since you use external power supply, you can easily check if the battery is charging, check the power draw without the battery, and check again with the battery. If the battery is charging the current draw should be considerably higher.
#4
A64 / Battery wont charge
Last post by mauricio - June 23, 2026, 09:45:16 PMI have an olinuxino A64, rev. G (two of them), I'm running tests on it, with an attached lipo battery, trying to implement a gracefull shutdown when no main DC current is detected.
uname -r
5.10.180-olimex
cat /etc/os-release | grep PRETTY_NAME
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
For that, I started to look at /sys/class/power_supply/ files.
=== BATTERY SYSTEM ===
capacity: 47
constant_charge_current: 1000000
constant_charge_current_max: 1200000
current_now: 2000
health: Good
online: 1
present: 1
status: Charging
type: Battery
uevent: POWER_SUPPLY_NAME=axp20x-battery
POWER_SUPPLY_TYPE=Battery
POWER_SUPPLY_PRESENT=1
POWER_SUPPLY_ONLINE=1
POWER_SUPPLY_STATUS=Charging
POWER_SUPPLY_VOLTAGE_NOW=3806000
POWER_SUPPLY_CURRENT_NOW=2000
POWER_SUPPLY_CONSTANT_CHARGE_CURRENT=1000000
POWER_SUPPLY_CONSTANT_CHARGE_CURRENT_MAX=1200000
POWER_SUPPLY_HEALTH=Good
POWER_SUPPLY_VOLTAGE_MAX_DESIGN=4200000
POWER_SUPPLY_VOLTAGE_MIN_DESIGN=2900000
POWER_SUPPLY_CAPACITY=47
voltage_max_design: 4200000
voltage_min_design: 2900000
voltage_now: 3806000
=== AC PLUG SYSTEM ===
health: Good
input_current_limit: 1500000
online: 1
present: 1
type: Mains
uevent: POWER_SUPPLY_NAME=axp813-ac
POWER_SUPPLY_TYPE=Mains
POWER_SUPPLY_HEALTH=Good
POWER_SUPPLY_PRESENT=1
POWER_SUPPLY_ONLINE=1
POWER_SUPPLY_VOLTAGE_MIN=4000000
POWER_SUPPLY_INPUT_CURRENT_LIMIT=1500000
voltage_min: 4000000
My problem is that batteries wont charge on A64 (just tryed one of them, because the other one is far from me), but they charge very well on an olinuxino micro A20.
I'm wondering if this just happening just to me or is an A64, rev. G software/hardware/OS situation.
Also, as aditional info, I'm powering the A64 from an adjustable power source, I can see voltages and current given by it, it's giving 5.2V and ~330mA, even when the limit set to the power source is 2Amps.
This last battery I tried, has two hours stucked in these values (also the adjustable power source)
Tue Jun 23 14:00:38 -04 2026
Status: Charging
Capacity (%): 47
Current (uA): 2000 (<---this value only changes between 1000 and 2000)
Voltage (uV): 3806000
If I unplug the power barrel jack, the values change to this
Tue Jun 23 14:02:34 -04 2026
Status: Discharging
Capacity (%): 47
Current (uA): -478000
Voltage (uV): 3687000
Please also note, that the first battery I tryed, at A64, get stucked at 66% charge, like this
Charging
66
1000 (<---this value only changes between 1000 and 2000)
3896000
At the A20, this battery, after two hours of charge says
14:16:15
99
4176000
124000
So I need to ask:
Do I need to do some extra stuff to get the battery to charge ?
Is this normal behavior ? May I suspect a fail PMIC ?
What may I do to improve the charge ?
Please let me know, thanks
uname -r
5.10.180-olimex
cat /etc/os-release | grep PRETTY_NAME
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
For that, I started to look at /sys/class/power_supply/ files.
=== BATTERY SYSTEM ===
capacity: 47
constant_charge_current: 1000000
constant_charge_current_max: 1200000
current_now: 2000
health: Good
online: 1
present: 1
status: Charging
type: Battery
uevent: POWER_SUPPLY_NAME=axp20x-battery
POWER_SUPPLY_TYPE=Battery
POWER_SUPPLY_PRESENT=1
POWER_SUPPLY_ONLINE=1
POWER_SUPPLY_STATUS=Charging
POWER_SUPPLY_VOLTAGE_NOW=3806000
POWER_SUPPLY_CURRENT_NOW=2000
POWER_SUPPLY_CONSTANT_CHARGE_CURRENT=1000000
POWER_SUPPLY_CONSTANT_CHARGE_CURRENT_MAX=1200000
POWER_SUPPLY_HEALTH=Good
POWER_SUPPLY_VOLTAGE_MAX_DESIGN=4200000
POWER_SUPPLY_VOLTAGE_MIN_DESIGN=2900000
POWER_SUPPLY_CAPACITY=47
voltage_max_design: 4200000
voltage_min_design: 2900000
voltage_now: 3806000
=== AC PLUG SYSTEM ===
health: Good
input_current_limit: 1500000
online: 1
present: 1
type: Mains
uevent: POWER_SUPPLY_NAME=axp813-ac
POWER_SUPPLY_TYPE=Mains
POWER_SUPPLY_HEALTH=Good
POWER_SUPPLY_PRESENT=1
POWER_SUPPLY_ONLINE=1
POWER_SUPPLY_VOLTAGE_MIN=4000000
POWER_SUPPLY_INPUT_CURRENT_LIMIT=1500000
voltage_min: 4000000
My problem is that batteries wont charge on A64 (just tryed one of them, because the other one is far from me), but they charge very well on an olinuxino micro A20.
I'm wondering if this just happening just to me or is an A64, rev. G software/hardware/OS situation.
Also, as aditional info, I'm powering the A64 from an adjustable power source, I can see voltages and current given by it, it's giving 5.2V and ~330mA, even when the limit set to the power source is 2Amps.
This last battery I tried, has two hours stucked in these values (also the adjustable power source)
Tue Jun 23 14:00:38 -04 2026
Status: Charging
Capacity (%): 47
Current (uA): 2000 (<---this value only changes between 1000 and 2000)
Voltage (uV): 3806000
If I unplug the power barrel jack, the values change to this
Tue Jun 23 14:02:34 -04 2026
Status: Discharging
Capacity (%): 47
Current (uA): -478000
Voltage (uV): 3687000
Please also note, that the first battery I tryed, at A64, get stucked at 66% charge, like this
Charging
66
1000 (<---this value only changes between 1000 and 2000)
3896000
At the A20, this battery, after two hours of charge says
14:16:15
99
4176000
124000
So I need to ask:
Do I need to do some extra stuff to get the battery to charge ?
Is this normal behavior ? May I suspect a fail PMIC ?
What may I do to improve the charge ?
Please let me know, thanks
#5
DUINOMITE / Re: Displays for Duinomite
Last post by LubOlimex - June 22, 2026, 01:41:56 PMI understand, I didn't mean to defend us either, I just wanted to clarify here what was the change exactly in case somebody else encounters similar issue.
#6
DUINOMITE / Re: Displays for Duinomite
Last post by KeesZagers - June 22, 2026, 11:57:51 AMHi Lub, I agree that it is mentioned in the product page, however if you want to copy an existing installation, you don't read all the specifications again. As long as the product is upwards compatible, no problem; however if this is not the case it is better to make the old version obsolete and replace it by a new one. In that case you are more prepared that you have to do additional work. Anyway the reason I wrote it on the Duinomite pages on this forum is that users of the Duinomite products with my Basic software are also notified of the incompatibility.
#7
DUINOMITE / Re: Displays for Duinomite
Last post by LubOlimex - June 22, 2026, 08:48:53 AMKees, there was a change in the touch driver 3 or 4 years ago, the original one was AR1021 and the new one is NS2009 - this is mentioned on the product page and hardware revision changes and we also released a new demo for NS2009 here:
https://github.com/OLIMEX/MOD-LCD2.8RTP/tree/master/SOFTWARE/Arduino
https://github.com/OLIMEX/MOD-LCD2.8RTP/tree/master/SOFTWARE/Arduino
#8
DUINOMITE / Displays for Duinomite
Last post by KeesZagers - June 20, 2026, 03:50:44 PMBased on the old DMBasic 2.7 I developed my own extensions to Basic, e.g. for all kind of CAN commands, but also some other controls as two kind of displays. The MOD-OLED-128x64 and the MOD-LCD2.8RTP are supported by one Basic statement called OLED which copies the VGA memory on to the screen. Also the touch screen of the MOD-LCD2.8RTP is supported by this statement. This week I ordered a new display module and determined that the touch is not working. Reading the details of the product, I noticed that the touch controller has been changed and the software seems not to be compatible. I will try to make the OLED statement also compatible with the new controller. For those people using my free software be noticed. For Olimex: If a product has software which is not upwards compatible with an old version, give it a new number, or at least specify it more clearly.
#9
A64 / Overheating on mainline Linux
Last post by Roman - June 20, 2026, 12:48:44 PMWith the current Linux-libre, I observe that A64-OLinuXino may overheat under heavy prolonged load.
Interestingly, when I try "stress-ng -c 0", which fully loads all four cores of the CPU, the temperature stabilizes right above the default lower temperature trip point of 75 degrees, even without a heatsink and in BOX-A64-BLACK inside an unventilated cabinet. But that load is synthetic and even.
Under a real-world load, for example, when I run "guix pull", which produces an uneven load over a long period of time (probably an hour), the temperature drifts and at some point may exceed 110 degrees. The last message that I see in the serial console says that 110 degrees were reached and the device is going into reboot. The reboot probably happens too fast for the chip to cool down because the board never starts by itself.
I conclude that the temperature fluctuates too fast under an uneven high load. The default configuration of the kernel does not handle that well. The configuration could probably be changed by configuring the power allocator. But I think that adding even a small heatsink on the A64 BGA should completely resolve the issue. The heatsink will be absorbing heat and should smooth the temperature spikes.
Olimex lists ALUMINIUM-HEATSINK-20x20x6MM as a related product for Allwinner A64. I suppose that it is appropriate for the task. I also saw a member of the forum reporting that a 15x15x15 is the right size for A64 and fits perfectly inside BOX-A64-BLACK. A datasheet for A64 says that it comes in "15x15mm" FBGA396 package. So, I probably should be looking for a 15x15 heatsink. Most of the readily available radiators are 14x14 mm in my local market, however.
If anyone has any advice on preventing overheating or on choosing a heatsink, it will be much appreciated.
Interestingly, when I try "stress-ng -c 0", which fully loads all four cores of the CPU, the temperature stabilizes right above the default lower temperature trip point of 75 degrees, even without a heatsink and in BOX-A64-BLACK inside an unventilated cabinet. But that load is synthetic and even.
Under a real-world load, for example, when I run "guix pull", which produces an uneven load over a long period of time (probably an hour), the temperature drifts and at some point may exceed 110 degrees. The last message that I see in the serial console says that 110 degrees were reached and the device is going into reboot. The reboot probably happens too fast for the chip to cool down because the board never starts by itself.
I conclude that the temperature fluctuates too fast under an uneven high load. The default configuration of the kernel does not handle that well. The configuration could probably be changed by configuring the power allocator. But I think that adding even a small heatsink on the A64 BGA should completely resolve the issue. The heatsink will be absorbing heat and should smooth the temperature spikes.
Olimex lists ALUMINIUM-HEATSINK-20x20x6MM as a related product for Allwinner A64. I suppose that it is appropriate for the task. I also saw a member of the forum reporting that a 15x15x15 is the right size for A64 and fits perfectly inside BOX-A64-BLACK. A datasheet for A64 says that it comes in "15x15mm" FBGA396 package. So, I probably should be looking for a 15x15 heatsink. Most of the readily available radiators are 14x14 mm in my local market, however.
If anyone has any advice on preventing overheating or on choosing a heatsink, it will be much appreciated.
Code Select
$ uname -r
7.0.12-arm64-generic
$ cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor | uniq
schedutil
$ ls -l /sys/class/thermal/thermal_zone*/cdev*
lrwxrwxrwx 1 root root 0 Jun 20 12:18 /sys/class/thermal/thermal_zone0/cdev0 -> ../cooling_device0
-r--r--r-- 1 root root 4096 Jun 20 12:18 /sys/class/thermal/thermal_zone0/cdev0_trip_point
-rw-r--r-- 1 root root 4096 Jun 20 12:18 /sys/class/thermal/thermal_zone0/cdev0_weight
lrwxrwxrwx 1 root root 0 Jun 20 12:18 /sys/class/thermal/thermal_zone0/cdev1 -> ../cooling_device0
-r--r--r-- 1 root root 4096 Jun 20 12:18 /sys/class/thermal/thermal_zone0/cdev1_trip_point
-rw-r--r-- 1 root root 4096 Jun 20 12:18 /sys/class/thermal/thermal_zone0/cdev1_weight
$ cat /sys/class/thermal/cooling_device0/type
cpufreq-cpu0
$ cat /sys/class/thermal/thermal_zone0/trip_point_1_type
hot
$ cat /sys/class/thermal/thermal_zone0/trip_point_0_type
passive
$ cat /sys/class/thermal/thermal_zone0/trip_point_0_temp
75000
$ cat /sys/class/thermal/thermal_zone0/cdev0_trip_point
0
$ cat /sys/class/thermal/thermal_zone0/cdev1_trip_point
1
$ cat /sys/class/thermal/thermal_zone0/trip_point_0_hyst
2000
$ cat /sys/class/thermal/thermal_zone0/k_po
0
$ cat /sys/class/thermal/thermal_zone0/k_d
0
$ cat /sys/class/thermal/thermal_zone0/sustainable_power
0
#10
ESP32 / Re: ESP32-PoE-ISO UART1 issue
Last post by LubOlimex - June 18, 2026, 04:50:04 PMHere is the experimental firmware version 6 - it should have better support for half duplex mode and work fine with Modbus:
https://www.olimex.com/Products/Modules/Interface/MOD-RS485-ISO/resources/MOD-RS485_FIRMWARE_V6.zip
There is also Arduino library and examples inside (ZIP the sub-folder and import in Arduino IDE).
Changing the firmware of MOD-RS485-ISO requires PIC-compatible programmer, there is a hex inside the archive, load it on each RS485-ISO board.
I tested the examples with ESP32-POE-ISO and all seems to work fine but feedback is more than welcome.
https://www.olimex.com/Products/Modules/Interface/MOD-RS485-ISO/resources/MOD-RS485_FIRMWARE_V6.zip
There is also Arduino library and examples inside (ZIP the sub-folder and import in Arduino IDE).
Changing the firmware of MOD-RS485-ISO requires PIC-compatible programmer, there is a hex inside the archive, load it on each RS485-ISO board.
I tested the examples with ESP32-POE-ISO and all seems to work fine but feedback is more than welcome.