EdgeTX
RTC time not being kept on RadioMaster MT12
Is there an existing issue for this problem?
- [X] I have searched the existing issues
What part of EdgeTX is the focus of this bug?
Transmitter firmware
Current Behavior
When the radio is powered off, the time resets to 2000-1-1 even though the RTC battery is 2.97v.
Expected Behavior
The radio should remember the date and time it was set to.
Steps To Reproduce
Set the time to anything. Power off radio The time will reset
Version
Nightly (Please give date/commit below)
Transmitter
RadioMaster MT12
Operating System (OS)
macOS
OS Version
No response
Anything else?
I am (was) running yesterday’s nightly 1/13/24. The problem instantly resolved once I switched to an older nightly which I had on my computer. I saw that someone else had this issue in #5779 with a different radio.
If it's a software problem it would help to know which nightly works for you. That might make it easier to pinpoint.
Oh sorry I guess I didn’t mention the version that works. It’s the 2024-09-30 one.
Hello I have exactly the same problem:
- Radiomaster MT12
- the time resets to 2000-1-1
- RTC batt at 2.95V
Problem happen with the nightly : mt12-36f2b6a.bin (9 february 2025 )
No problem with the nightly : mt12-0ea41f2.bin ( end of november 2024 i guess)
It is important for me because I have a big LUA script which record log files of my sessions (lap time, telemetry data, ...) named with the date/hour
thanks
Please can someone could build for us several old nightly firmware for the MT12 (between the Nov 29, 2024 and now )
Dec 6 2024 : https://github.com/EdgeTX/edgetx/tree/3d1e7a914f729fffa77b15d3c3754bfa26f0e6e5 Dec 22 2024 : https://github.com/EdgeTX/edgetx/tree/2b920a014b0d69684eecfc20a74855d8b553e005 Jan 15 2025 : https://github.com/EdgeTX/edgetx/tree/795cc35b8d357825944665f99d824f9c4cd0ca28 Jan 21 2025 : https://github.com/EdgeTX/edgetx/tree/d9f4667cfd410a7124c9765719a55a679a25d96b
In order to we could find when the issue began (testing on my MT12)
We already know that there is no problem before the Nov 29, 2024
thank you
Ok I isolate the problem :
The issue is in the commit #5693 or #5686 or #5617 or #5699
Because the commit 0ea41f2 work correctly and in the 3d1e7a9 the RTC time reset to 2000 1 1
@pfeerick can you investigate this please?
thanks
Thanks for whittling that down.
Won't be #5617 as not related firmware, #5693 and #5699 do not apply to B&W radios. Leaving #5686, which is a likely candidate since it specifically has some RTC changes which will effect the MT12.
I was able to reproduce the time reset with v2.11-rc1 on MT12 after entering the bootloader. A simple power on/off with only a few seconds delay (as well as a couple of hours) between did not lose the time/date. It appears a DFU flash may also reset the time.
Hmmm, 5686 should be harmless, and is not specifically targeting MT12, but all BW. A DFU flash doesn't involve any Etx code at all, so really intriguing
I suspect the DFU issue is similar to that of the Zorro - i.e. a hardware issue. With regards to the MT12, ATM I think it is important to just identify all the possible triggers for the RTC to reset, and then try and backtrack why it might be happening. e.g. I don't even have to perform a DFU update... simply plugging in and unplugging the USB is enough to make it lose the time. And I'm sorry to report, but after removing just the merge commit for #5686, entering the bootloader on my MT12 no longer causes it to lose the time.
Interestingly, the TX12MKII also lost its time on DFU update (so perhaps this is an issue across several handset models?, and just needs to be documented as a known issue since there is nothing we can do about it). However, going into the bootloader several times didn't result in the time being lost. And neither T12MAX nor GX12 lost time going into DFU or bootloader.
On Wed, Feb 12, 2025 at 6:43 PM 3djc @.***> wrote:
Hmmm, 5686 should be harmless, and is not specifically targeting MT12, but all BW. A DFU flash doesn't involve any Etx code at all, so really intriguing
— Reply to this email directly, view it on GitHub https://github.com/EdgeTX/edgetx/issues/5782#issuecomment-2653008701, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABJ66KKB6CT5NW4CGADFFED2PMCSDAVCNFSM6AAAAABVFEP7S6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNJTGAYDQNZQGE . You are receiving this because you were mentioned.Message ID: @.***>
I suspect the DFU issue is similar to that of the Zorro - i.e. a hardware issue. With regards to the MT12, ATM I think it is important to just identify all the possible triggers for the RTC to reset, and then try and backtrack why it might be happening. e.g. I don't even have to perform a DFU update... simply plugging in and unplugging the USB is enough to make it lose the time. And I'm sorry to report, but after removing just the merge commit for #5686, entering the bootloader on my MT12 no longer causes it to lose the time.
Interestingly, the TX12MKII also lost its time on DFU update (so perhaps this is an issue across several handset models?, and just needs to be documented as a known issue since there is nothing we can do about it). However, going into the bootloader several times didn't result in the time being lost. And neither T12MAX nor GX12 lost time going into DFU or bootloader. …
@pfeerick ,how did you manage to make it work ? Because I tried with a custom build based on the current 2.11 RC1 and just removing the corresponding line of the #5686 in the code (main.cpp and Cmakelists.txt) and it doesnt work (issue is always there)
Did I do something wrong?
Are you doing a DFU flash or just a firmware flash ?
Tested https://github.com/EdgeTX/edgetx/pull/5902 and I don't loose time here with MT12
humm I dont really know the difference I build the .bin file then flash using this method: https://manual.edgetx.org/installing-and-updating-edgetx/update-from-an-earlier-version-of-edgetx-using-the-bootloader
and after the flash i repeat these steps below 4 times to be sure:
- set the date to 2025
- power off the radio
- wait from 10 sec to 5 min
- power on the radio : the date was reset to 2020
You should try with DFU (connect USB while radio is off). You can use Companion to do it using Read/Write then Write firmware to radio
You should try with DFU (connect USB while radio is off). You can use Companion to do it using Read/Write then Write firmware to radio
OK i will try this tonight
@3djc , another question: I only use these options to build the firmware :
-DPCB=X7 -DPCBREV=MT12 -DDEFAULT_MODE=2 -DCMAKE_BUILD_TYPE=Release
Is this OK ?
ok @3djc , I flashed via DFU your #5902 and:
at first power on (after the flashing) the time is ok
at second power off/on cycle the time is reset
So doesnt work sorry
@pfeerick ,how did you manage to make it work ? Because I tried with a custom build based on the current 2.11 RC1 and just removing the corresponding line of the https://github.com/EdgeTX/edgetx/pull/5686 in the code (main.cpp and Cmakelists.txt) and it doesnt work (issue is always there)
I just reverted the merge commit for that PR:
git revert 0ed1b94
btw,
FLAVOR=mt12 tools/build-gh.sh is much easier and less error prone if you want to build firmware (if it is a one-off build, rather than when making incremental changes).
set the date to 2025 power off the radio wait from 10 sec to 5 min power on the radio : the date was reset to 2020
This unfortunately I can't reproduce... I can leave it even a couple of hours and time was still retained (this was with 2.11.0-rc1 firmware)... so perhaps entering the bootloader first is triggering a different fault.
I made other test, to summarize :
- flash with the mt12-0ea41f2.bin (2.11 november 2024 nightly): .bin file already built downloaded on the website
At each power off/on of the radio : No problem at all
- flash with the mt12-f51c67a.bin (2.11 RC1): .bin file already built downloaded on the website
At each power off/on of the radio : the date/time reset to 2020 1 1 0:0:0
- flash with the mt12-f51c67a.bin but reverting the commit #5686 (2.11 RC1 without #5686 ): .bin built with this tutorial : https://github.com/EdgeTX/edgetx/wiki/Building-radio-firmware-in-a-webbrowser-with-Gitpod
At each power off/on of the radio : the date/time reset to 2020 1 1 0:0:0
- flash with the mt12-f51c67a.bin but reverting the commit #5686 (2.11 RC1 without #5686 ): .bin built with this command line: FLAVOR=mt12 tools/build-gh.sh
At each power off/on of the radio : the date/time is conserved
BUT, during my test, at about the seventh power on/off cycle the date/time was reseted one time
and no problem since
On a somewhat unrelated note, I decided to build the Dec 6 nightly (https://github.com/EdgeTX/edgetx/tree/3d1e7a914f729fffa77b15d3c3754bfa26f0e6e5) for myself to get the Set Screen function as I thought the issue might not be present, but nope, after the first restart it loses the time completely 🫠
I used Buddy to install as I always have done.
Back to my trusty 9/30/24 nightly :)
@inventor7777 , try this one: https://github.com/Gjeremie/edgetx-JG-2.11-RC1/tree/revert-5686-3djc/bw-f4-em/Firmware it's the 2.11 RC1 but without the #5686
and it's seems to work ok with no time/date reset
@Gjeremie I tested it and it seems to work great! I restarted the radio a bunch of times with no reset 🥳
However, oddly enough, the radio says it’s running EdgeTX 3.0.0….
Removing RTC Backup is not world best idea, albeit it might be less critical on a surface radio I guess
What is the RTC backup used for?
I will try your #5911 if it resolve the issue
When things go bad (could be software issue, interference, hardware glitch), a hardware watchdogs resets the radio and signals something bad happened. When restarting, EdgeTX detect the "something went bad" info, and expedite an emergency fast start (things like switch position and all are skipped) which goal is to give you bad control of your model. You can identify this condition, if it ever happens, by a blinking '!' character top left of MT12 screen. RTC Backup plays a key role in that
However, oddly enough, the radio says it’s running EdgeTX 3.0.0….
Which means that is from the main branch, not 2.11 branch ;) Main and 2.11 are pretty much identical atm though.
Removing RTC Backup is not world best idea,
True, but given it wasn't actually enabled for B&W F4 until now, it's also not that much of a loss 🤭 However, in my view omitting #5686 is only a workaround, while we figure out a solution (assuming it is a soft bug), while also highlighting what change is triggering the time loss.
Still, between the risk of loosing time, and the risk of loosing models, I would choose to fix the later, and to some extent is a tribute to show how stable BW radio are software wise, EM are quite rare on those. And yes, it's clearly not a hard bug since it is only affecting few users