RTC time not being kept on RadioMaster MT12

[inventor7777]

Is there an existing issue for this problem?

• 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.

[philmoz]

If it's a software problem it would help to know which nightly works for you. That might make it easier to pinpoint.

[philmoz]

FWIW my MT12 does not reset the RTC clock with current main branch.

[inventor7777]

Oh sorry I guess I didn’t mention the version that works. It’s the 2024-09-30 one.

[Gjeremie]

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

[Gjeremie]

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

[Gjeremie]

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

[pfeerick]

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.

[3djc]

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

[pfeerick]

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 <#5782 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJ66KKB6CT5NW4CGADFFED2PMCSDAVCNFSM6AAAAABVFEP7S6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNJTGAYDQNZQGE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[3djc]

@Gjeremie , could you try #5902 ?

[Gjeremie]

@Gjeremie , could you try #5902 ?

@3djc , I tried and It doesnt work

[Gjeremie]

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?

[3djc]

Are you doing a DFU flash or just a firmware flash ?

Tested #5902 and I don't loose time here with MT12

[Gjeremie]

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

[3djc]

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

[Gjeremie]

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

[Gjeremie]

@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 ?

[3djc]

Sure

[Gjeremie]

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

[3djc]

Could you try with a new battery ? (Yes I know it works with older versions)

[pfeerick]

@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)

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.

[Gjeremie]

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

[inventor7777]

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 :)

[Gjeremie]

@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

[inventor7777]

@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….

[3djc]

Removing RTC Backup is not world best idea, albeit it might be less critical on a surface radio I guess

[Gjeremie]

What is the RTC backup used for?

I will try your #5911 if it resolve the issue

[3djc]

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

[pfeerick]

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.

[3djc]

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

[Gjeremie]

I hope I will never experience an EM on my MT12 but how long does it take to recover the control of the model?

And anyway EM is not acceptable for a radio. It should not occur during a race. Never have one on my old sanwa or futaba radio.

[hawku]

@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

Just tested 2.11-RC1 on my MT12 and got an RTC reset after the first power cycle.
@Gjeremie 's firmware doesn't reset the RTC after power cycle.
Original "MT12-edgetx,2.10.0-12232023.bin" firmware doesn't reset the time
Radio indicates the RTC voltage as 2.69V, so my results might not be that reliable.

[inventor7777]

So I tested the latest 2/14/25 Nightly with both of my MT12s (one is a very, very early model that I had imported back in late 2023 when they were first released, and the other is a standard one I bought a few months ago) and they both reset the time after a minute of being off. I then built the exact same firmware in Gitpod with git revert 0ed1b94 and the problem instantly disappeared.

You can download my custom firmware here - https://github.com/inventor7777/EdgeTX-RTC-Fix/releases/tag/3.0

[pfeerick]

I hope I will never experience an EM on my MT12 but how long does it take to recover the control of the model?

Hard to quantify, as it is may also be a question of how long does it take for the RF link to re-establish. Firmware itself will usually recover in well under a second on B&W... faster if it can use the RTC backup memory and skip SD card re-init.

And anyway EM is not acceptable for a radio. It should not occur during a race. Never have one on my old sanwa or futaba radio.

Any why does the radio care about whether you are racing or not? 🤪 EMs are very rare, and outside of the odd software bug being the culprit, IMO tend to be somewhat hardware related (brownout, storage failure, etc) or a Lua script somehow doing something out of bounds or some other user-induced gremlin. But the realistic alternative is a complete handset lockup, or a handset with no Lua, no customisation of sounds, limited configuration options overall, etc, etc.. neither of which are desirable.

[inventor7777]

I can vouch for the reliability of these radios. I’ve been using my MT12 on average 4 times a day since late 2023 and I’ve customized everything and I’ve never had any serious issues, except one that’s kind of my fault. I even got rainwater inside mine and it worked fine (until I tried to turn it back on later, lol). I did end up fixing it soon after.

[pfeerick]

I even got rainwater inside mine

I'm sorry, we don't have exception handling for that 🤣 My TX16S and other handsets have had some light rain exposure over the years and have thankfully coped after being left to dry out..