Crosspoint

835 Commits 20 Branches 33 Tags

3 Commits

Include renames

Author	SHA1	Message	Date
Xuan-Son NguyenandZach Nelson	e1b74c9db5	fix: use sleep routine from the original firmware (#1298 ) ## Summary Fixes #1263 I spent half of my day(-off) reverse engineering the stock english firmware V3.1.1, it's more or less like solving a sudoku with some known pieces (like debug strings, known static addresses, known compiled function, etc) and then the task is to guess the rest. Long story short, this is the sleep routine that they use: <img width="674" height="604" alt="image" src="https://github.com/user-attachments/assets/6d53ce44-7bae-40c7-b4fb-24f898dbcc05" /> From the code above: - They pull down GPIO13 (value = 0xd) before sleep - They verify that power button is released by doing a delay loop of 50ms, similar to what we're doing - `esp_sleep_config_gpio_isolate` is called but I'm not 100% sure why - Pull up power button, note that it's likely redundant because power button should already pulled up by `InputManager` - `param1` and `param2` means enabling front/side buttons for wake up, but it doesn't used in the code in reality. But I think it's physically impossible, see the explanation below - `param3` means "wake up from power button" - `esp_sleep_start` is used; there is a logic to handle if it fails to sleep, then retry recursively (no idea why!) My observation is that they use GPIO13 so that it will be on HIGH state when the chip is powered on, without any user space code to keep it on that state. And once going to deep sleep, it goes into FLOATING by default. That may explain why it need to be in LOW state before going to sleep. (Nice trick btw) Looking again at the circuit diagram provided [here](https://github.com/sunwoods/Xteink-X4/blob/main/readme-img/sch.jpg) (note: it's not official): <img width="705" height="384" alt="image" src="https://github.com/user-attachments/assets/b98d59fd-47ca-4d3d-a24a-94bf999e957b" /> It kinda make sense as the GPIO13 and VBUS (USB VCC) have the same role, they are part of a simple "battery protection" cirtuit Now, we may wonder, how the device wake up when there is no battery at all? <img width="440" height="323" alt="image" src="https://github.com/user-attachments/assets/2981c411-239b-49a7-b9f7-9a75b6c1b6d3" /> It seems like power button is not just a simple switch between GPIO3 and ground, but it also linked the POWER_CTRL, which leads to nowhere on the diagram, but I suppose it connects the battery back for a short amount of time, just enough for the MCU to wake up, and GPIO13 goes HIGH again. It may also explain why power button becomes non-responsive for ~1 second after power on, as it's being pulled up by the current from battery (remind: high = not pressed, low = pressed) To test the theory above, I simply comment out the `esp_deep_sleep_enable_gpio_wakeup`: - On battery, power button works as nothing happen - On USB, it doesn't wake up, I need to press RST --- Important things about my analysis: 1. I had to name every function on the code above manually, but I'm 99% confident about it. The only function that I'm not sure is `esp_wifi_bt_power_domain_off` ; Edit: it was indeed mislabeled, see https://github.com/crosspoint-reader/crosspoint-reader/pull/1298#discussion_r2879670852 2. Some logic inside the stock firmware looks very strange, there is almost no mention to "arduino" in the hardware, suggesting that they may just call esp-idf functions directly, bypassing the arduino abstraction. --- ### AI Usage While CrossPoint doesn't have restrictions on AI tools in contributing, please be transparent about their usage as it helps set the right context for reviewers. Did you use AI tools to help write this code? NO --------- Co-authored-by: Zach Nelson <zach@zdnelson.com>	2026-03-21 13:35:38 -05:00
Vincent Politzer	0bfd018a9f	fix: Use HalPowerManager for battery percentage (#1005 ) ## Summary The introduction of `HalGPIO` moved the `BatteryMonitor battery` object into the member function `HalGPIO::getBatteryPercentage()`. Then, with the introduction of `HalPowerManager`, this function was moved to `HalPowerManager::getBatteryPercentage()`. However, the original `BatteryMonitor battery` object is still utilized by themes for displaying the battery percentage. This PR replaces these deprecated uses of `BatteryMonitor battery` with the new `HalPowerManager::getBatteryPercentage()` function. --- ### AI Usage While CrossPoint doesn't have restrictions on AI tools in contributing, please be transparent about their usage as it helps set the right context for reviewers. Did you use AI tools to help write this code? _NO _	2026-02-20 00:05:35 +01:00
Xuan-Son Nguyen	d4b1146d9f	feat: lower CPU freq on idle, add HalPowerManager (#852 ) ## Summary Continue my experiment from https://github.com/crosspoint-reader/crosspoint-reader/pull/801 This PR add the ability to lower the CPU frequency on extended idle period (currently set to 3 seconds). By default, the esp32c3 CPU is set to 160MHz, and now on idle, we can reduce it to just 10MHz. Note that while this functionality is already provided by [esp power management](https://docs.espressif.com/projects/esp-idf/en/v4.3/esp32c3/api-reference/system/power_management.html), the current Arduino build lacks of this, and enabling it is just too complicated (not worth the effort compared to this PR) Update: more info in https://github.com/crosspoint-reader/crosspoint-reader/pull/852#issuecomment-3904562827 ## Testing Pre-condition for each test case: the battery is charged to 100%, and is left plugged in after fully charged for an extra 1 hour. The table below shows how much battery is used for a given duration: \| case / duration \| 6 hrs \| 12 hrs \| \| --- \| --- \| --- \| \| `delay(10)` \| 26% \| 48% \| \| `delay(50)`, PR https://github.com/crosspoint-reader/crosspoint-reader/pull/801 \| 20% \| Not tested \| \| `delay(50)` + low CPU freq (This PR) \| Not tested \| 25% \| \| `delay(10)` + low CPU freq (1) \| Not tested \| Not tested \| (1) I decided not to test this case because it may not make sense. The problem is that CPU frequency vs power consumption do not follow a linear relationship, see [this](https://www.arrow.com/en/research-and-events/articles/esp32-power-consumption-can-be-reduced-with-sleep-modes) as an example. So, tight loop (10ms) + lower CPU freq significantly impact battery life, because the active CPU time is now much higher compared to the wall time. So in conclusion, this PR improves ~150% to ~200% battery use time per charge. The projected battery life is now: ~36-48 hrs of reading time (normal reading, no wifi) --- ### AI Usage While CrossPoint doesn't have restrictions on AI tools in contributing, please be transparent about their usage as it helps set the right context for reviewers. Did you use AI tools to help write this code? NO	2026-02-18 17:12:29 +03:00

Author

SHA1

Message

Date

Xuan-Son NguyenandZach Nelson

e1b74c9db5

fix: use sleep routine from the original firmware (#1298 )

## Summary

Fixes #1263

I spent half of my day(-off) reverse engineering the stock english
firmware V3.1.1, it's more or less like solving a sudoku with some known
pieces (like debug strings, known static addresses, known compiled
function, etc) and then the task is to guess the rest.

Long story short, this is the sleep routine that they use:

<img width="674" height="604" alt="image"
src="https://github.com/user-attachments/assets/6d53ce44-7bae-40c7-b4fb-24f898dbcc05"
/>

From the code above:
- They pull down GPIO13 (value = 0xd) before sleep
- They verify that power button is released by doing a delay loop of
50ms, similar to what we're doing
- `esp_sleep_config_gpio_isolate` is called but I'm not 100% sure why
- Pull up power button, note that it's likely redundant because power
button should already pulled up by `InputManager`
- `param1` and `param2` means enabling front/side buttons for wake up,
but it doesn't used in the code in reality. But I think it's physically
impossible, see the explanation below
- `param3` means "wake up from power button"
- `esp_sleep_start` is used; there is a logic to handle if it fails to
sleep, then retry recursively (no idea why!)

My observation is that they use GPIO13 so that it will be on HIGH state
when the chip is powered on, without any user space code to keep it on
that state. And once going to deep sleep, it goes into FLOATING by
default. That may explain why it need to be in LOW state before going to
sleep. (Nice trick btw)

Looking again at the circuit diagram provided
[here](https://github.com/sunwoods/Xteink-X4/blob/main/readme-img/sch.jpg)
(note: it's not official):

<img width="705" height="384" alt="image"
src="https://github.com/user-attachments/assets/b98d59fd-47ca-4d3d-a24a-94bf999e957b"
/>

It kinda make sense as the GPIO13 and VBUS (USB VCC) have the same role,
they are part of a simple "battery protection" cirtuit

Now, we may wonder, how the device wake up when there is no battery at
all?

<img width="440" height="323" alt="image"
src="https://github.com/user-attachments/assets/2981c411-239b-49a7-b9f7-9a75b6c1b6d3"
/>

It seems like power button is not just a simple switch between GPIO3 and
ground, but it also linked the POWER_CTRL, which leads to nowhere on the
diagram, but I suppose it connects the battery back for a short amount
of time, just enough for the MCU to wake up, and GPIO13 goes HIGH again.
It may also explain why power button becomes non-responsive for ~1
second after power on, as it's being pulled up by the current from
battery (remind: high = not pressed, low = pressed)

To test the theory above, I simply **comment out** the
`esp_deep_sleep_enable_gpio_wakeup`:
- On battery, power button works as nothing happen
- On USB, it doesn't wake up, I need to press RST

---

Important things about my analysis:
1. I had to name every function on the code above **manually**, but I'm
99% confident about it. The only function that I'm not sure is
`esp_wifi_bt_power_domain_off` ; Edit: it was indeed mislabeled, see
https://github.com/crosspoint-reader/crosspoint-reader/pull/1298#discussion_r2879670852
2. Some logic inside the stock firmware looks very strange, there is
almost no mention to "arduino" in the hardware, suggesting that they may
just call esp-idf functions directly, bypassing the arduino abstraction.

---

### AI Usage

While CrossPoint doesn't have restrictions on AI tools in contributing,
please be transparent about their usage as it
helps set the right context for reviewers.

Did you use AI tools to help write this code? **NO**

---------

Co-authored-by: Zach Nelson <zach@zdnelson.com>

2026-03-21 13:35:38 -05:00

Vincent Politzer

0bfd018a9f

fix: Use HalPowerManager for battery percentage (#1005 )

## Summary

The introduction of `HalGPIO` moved the `BatteryMonitor battery` object
into the member function `HalGPIO::getBatteryPercentage()`.

Then, with the introduction of `HalPowerManager`, this function was
moved to `HalPowerManager::getBatteryPercentage()`.

However, the original `BatteryMonitor battery` object is still utilized
by themes for displaying the battery percentage.

This PR replaces these deprecated uses of `BatteryMonitor battery` with
the new `HalPowerManager::getBatteryPercentage()` function.

---

### AI Usage

While CrossPoint doesn't have restrictions on AI tools in contributing,
please be transparent about their usage as it
helps set the right context for reviewers.

Did you use AI tools to help write this code? _**NO **_

2026-02-20 00:05:35 +01:00

Xuan-Son Nguyen

d4b1146d9f

feat: lower CPU freq on idle, add HalPowerManager (#852 )

## Summary

Continue my experiment from
https://github.com/crosspoint-reader/crosspoint-reader/pull/801

This PR add the ability to lower the CPU frequency on extended idle
period (currently set to 3 seconds). By default, the esp32c3 CPU is set
to 160MHz, and now on idle, we can reduce it to just 10MHz.

Note that while this functionality is already provided by [esp power
management](https://docs.espressif.com/projects/esp-idf/en/v4.3/esp32c3/api-reference/system/power_management.html),
the current Arduino build lacks of this, and enabling it is just too
complicated (not worth the effort compared to this PR)

Update: more info in
https://github.com/crosspoint-reader/crosspoint-reader/pull/852#issuecomment-3904562827

## Testing

Pre-condition for each test case: the battery is charged to 100%, and is
left plugged in after fully charged for an extra 1 hour.

The table below shows how much battery is **used** for a given duration:

| case / duration | 6 hrs | 12 hrs |
| --- | --- | --- |
| `delay(10)` | 26% | 48% |
| `delay(50)`, PR
https://github.com/crosspoint-reader/crosspoint-reader/pull/801 | 20% |
Not tested |
| `delay(50)` + low CPU freq (This PR) | Not tested | 25% |
| `delay(10)` + low CPU freq (1) | Not tested | Not tested |

(1) I decided not to test this case because it may not make sense. The
problem is that CPU frequency vs power consumption do not follow a
linear relationship, see
[this](https://www.arrow.com/en/research-and-events/articles/esp32-power-consumption-can-be-reduced-with-sleep-modes)
as an example. So, tight loop (10ms) + lower CPU freq significantly
impact battery life, because the active CPU time is now much higher
compared to the wall time.

**So in conclusion, this PR improves ~150% to ~200% battery use time per
charge.**

The projected battery life is now: ~36-48 hrs of reading time (normal
reading, no wifi)

---

### AI Usage

While CrossPoint doesn't have restrictions on AI tools in contributing,
please be transparent about their usage as it
helps set the right context for reviewers.

Did you use AI tools to help write this code? **NO**

2026-02-18 17:12:29 +03:00