Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug]: Lilygo T-Echo - no autostart on external power connected on FW > 2.5.4 #5125

Closed
Monolith18 opened this issue Oct 21, 2024 · 11 comments
Closed
Labels
bug Something isn't working wontfix This will not be worked on

Comments

@Monolith18
Copy link

Monolith18 commented Oct 21, 2024

Category

Hardware Compatibility, Other

Hardware

T-Echo

Firmware Version

2.5.6, 2.5.7

Description

When T-Echo is off or with discharged battery. When connected external power source, regardless if this is power bank, or AC plug with USB cable, device will not autostart. On FW 2.5.4 and earlier, when in off or discharged condition and connected external power source device was starting. Tested with 2.5.6 and 2.5.7 (problematic). No problems with 2.5.4 and earlier.

Relevant log output

No response

@Monolith18 Monolith18 added the bug Something isn't working label Oct 21, 2024
@todd-herbert
Copy link
Contributor

This change will be the result of #4997.

I'm not 100% sure if this auto-start behavior was an intentional feature, or just a quirk.
I have to confess: my first thought was that this feels like a bug fixed, not a bug created, although now I think about it more, I can appreciate that there are situations where that auto-start is probably desirable.

This doesn't appear to impact all NRF52 devices. I tested RAK4631 + RAK19007 2nd gen just now, which does appear to autostart when charging begins. I believe RAK went out of their way to implement this as a hardware feature on their 2nd gen baseboard(?)

#4997 allows NRF52 devices to wake when the user button is pressed, instead of entering DFU. From a quick look at the bootloader code, I don't think we can have both behaviors: it's either "user button boots to fw" or "T-Echo autostarts when charging begins"

As a technical note: the decision between these two behaviors doesn't have to be made at compile time. Out of interest, what's your application here? We might be able to use different behavior depending on the device role, if it would be a sensible fix in this situation.

@Monolith18
Copy link
Author

Monolith18 commented Oct 22, 2024

I think this is a bug not a feature when it comes to T-Echo not autostarting. Since day 1 (don't remember which FW was that with my first T-Echo) autostart was something normal, out of the box. To put T-Echo unit into DFU mode user can quickly double press reset (RST) button. That's it. I don't know how RAK units work and what is the button configuration, but for T-Echo there was absolutely no problem nor conflict between autostart and using buttons for other functions. Switch on is one press RST button. Double press RST is DFU mode. Long press other button is shutdown.
Applications? Simple one. Unit can operate autonomously. I am not saying even about solar panels or power banks. Imagine T-Echo unit in remote cabin somehwere in the country, but with AC supply from the main grid. T-Echo can be powered with USB cable permanently and when there will be long power outage (remote locations are prone for that) eventually battery will run out of juice. Once power outage is finished and restored unit could start without anyones attention connecting back to the meshtastic grid.
I am not coder, so don't know how to fix that or revert back apart from going back to 2.5.4 FW which is last good one I know, but that means loosing new stuff and fixes from new FWs. If it is possible, I would like to have this feature back for T-Echo units.
Thanks!

@todd-herbert
Copy link
Contributor

todd-herbert commented Oct 22, 2024

To put T-Echo unit into DFU mode user can quickly double press reset (RST) button

I think I explained #4997 wrong. Before that change, if T-Echo (or another NRF52 device) is asleep, and the user button is pressed, the device enters DFU instead of booting. This wasn't a critical issue, but it was annoying.

but for T-Echo there was absolutely no problem nor conflict between autostart and using buttons for other functions

The conflict is between allowing boot from a user button press, or waking from battery-powered sleep when charging begins.

T-Echo can be powered with USB cable permanently and when there will be long power outage (remote locations are prone for that) eventually battery will run out of juice. Once power outage is finished and restored unit could start without anyones attention connecting back to the meshtastic grid.

I believe that this situation you're describing is a bit different. In that scenario, the battery runs dead flat. I'm not sure exactly what would happen. My guess is that the device will either auto-start when power is returned, or will become trapped in a brown-out state from the low battery voltage and be unable to boot without intervention.

I think that right now it is actually unsafe to allow your T-Echo to become fully discharged, as would happen in the remote cabin scenario you're describing. I don't believe that there is any code in the firmware which prevents NRF52 devices from reaching super-low voltages, and I'm not sure the T-Echo has any hardware protection against this either.

What I have just mentioned is a separate issue, but probably one that is worth looking into. I believe it was discussed quite some time ago but never fully resolved. If your main concern is that the device should reboot after a low-battery event, it might be a reasonable compromise to conditionally suppress the fix implemented by #4997 when entering a hypothetical low-battery shutdown It's an issue that would need close thought when addressing, as a solution would impact far more than just T-Echo devices.


@markbirss Is there some easy solution I'm missing here? Is there some value we can set in the GPREGRET register to have the bootloader skip dfu but still wake from battery-powered sleep when a 5V source is connected?

@Monolith18
Copy link
Author

Monolith18 commented Oct 22, 2024

But there was no issue with T-Echo at the very beginning. I don't know what other units/chipsets were doing. T-Echo when was asleep and you pressed RST button it simply restarted, same as not asleep or when screen paused, whatever. When screen was paused (semi-sleep I supossoe or something) just press the capacity button on the top and display was awake. There was no problem with DFU nor with asleep/awake, booting or whatever. I understand and appreciate that was annoying for other chipsets, but T-Echo was not affected by any problems like that. I don't know what protections against low, high or other voltage is inside. I bought T-Echo, because it is simple, no geek stuff required. I simply connect it to solar panel with usb/power bank/AC plug with USB and it works. Nothing else required. T-Echo was always autostarting by itself as soon power was back. Now with FW higher than 2.5.4 it is not possible, so out of the box feature of T-Echo is gone now. I am totally not referring to any other chipsets. If there was problem there I don't know. To enter DFU mode on T-Echo was simple. Just double press RST button. That's it. Simple and it works. Just auto start is bugged now :) I think a lot users want simple solutions. If the idea is to make meshtastic popular and widely used not only by the computer geeks and geniuses, needs to be working well with out of the box simple features, I think :D So please, make my T-Echo great again with autostart :D Thanks!

@liquidraver
Copy link

Just my two cents:
I'm glad I don't have to "re"shutdown my t-echos every time i connect (or disconnect!) the charger.
This is not a bug for me, but certainly an enhancement.

@Monolith18
Copy link
Author

So maybe solution would be to have option, either to have "legacy" behavior or "new" behavior. Let the users decide what they want to use at a time. I think that would be fair and not that difficult to implement.

@lyusupov
Copy link

lyusupov commented Oct 25, 2024

@todd-herbert

The conflict is between allowing boot from a user button press, or waking from battery-powered sleep when charging begins.

Use of VUSB supply signal as a wakeup source was inactivated in the LilyGO T-Echo factory default bootloader since three years ago, see this commit: lyusupov/Adafruit_nRF52_Bootloader@1224915

The reason for doing that is:
Most of users of the T-Echo for the purpose of SoftRF consider it as annoying behavior when the device makes an unwanted wake up from sleep once connected to an AC or 12V car USB charger. Every time it needs a user action to put the device back into sleep by the button press.

@thebentern thebentern added the wontfix This will not be worked on label Oct 25, 2024
@todd-herbert
Copy link
Contributor

I didn't realise they all shipped with the SoftRF bootloader! Do you know if the one linked in the Meshtastic doc is also built from the same fork? I did swap over to that at some point.

The reason for doing that is:
Most of users of the T-Echo for the purpose of SoftRF consider it as annoying behavior when the device makes an unwanted wake up from sleep once connected to an AC or 12V car USB charger. Every time it needs a user action to put the device back into sleep by the button press.

That would annoy me a whole lot too!

@liquidraver
Copy link

....and once disconnected! It woke up on disconnecting too.

@lyusupov
Copy link

lyusupov commented Oct 25, 2024

image

I didn't realise they all shipped with the SoftRF bootloader!

a) https://github.com/lyusupov/SoftRF/tree/master/software/firmware/binaries/nRF52840/Adafruit_nRF52_Bootloader
b) https://github.com/Xinyuan-LilyGO/T-Echo/tree/main/bootloader

$ diff a/lilygo_techo_bootloader-0.6.1_s140_6.1.1.hex b/lilygo_techo_bootloader-0.6.1_s140_6.1.1.hex
$

....and once disconnected!

they both trigger the same POWER_RESETREAS_VBUS hardware event. Thus, both should keep nRF52840 MCU in OFF state when the LilyGO T-Echo factory bootloader is installed.

@todd-herbert
Copy link
Contributor

Ah I missed the Xinyuan-LilyGO fork! I'll definitely know to look there in future, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

5 participants