RTC not advancing when USB power disconnected

[jfceklosky]

I have noticed that the RTC is not advancing when the USB power is disconnected.

I have a lithium ion battery installed and that shows 3.3 volts at the VBAT on the STM32. The clock retains it's value but it is not running when the USB power is disconnected.

NOTE: I created a modified version of the hardware, but my connections are exactly the same as the original hardware design.

PCB Front:

PCB Back:

[retro16]

Hi, thanks a lot for your feedback.

Since the clock retains its value, you can be 100% sure that your hardware is correct. The RTC unit only needs some voltage on the VBAT pin to run, all the required hardware is already on the blue pill, there is no trap.

Can you try the RTClock/RTCAdjust sample available in Arduino on your hardware (disconnected from the ST of course) ? If it works correctly, can you try again ACSI2STM to see if running the sample changed anything ?

I highly suspect that I am missing some initialization somewhere, and that it was properly initialized by running this sample during development.

JM

[jfceklosky]

JM,

I will give that a try.
I found this tutorial before you replied and was thinking along the same lines.

https://mischianti.org/2023/05/02/stm32-internal-rtc-clock-and-battery-backup-vbat/

Joe

[jfceklosky]

I have not had a chance to dig in and test the clock in code and testing, but in here

whatever your path is/Arduino_STM32/STM32F1/libraries/RTClock/examples/Test_RTClock

There are examples for the RTC each example does the following:

RTClock rt (RTCSEL_LSE); // initialise

Which I did not find in the current code 4.10 code base.

[jfceklosky]

I am still testing the clock using the example here Arduino_STM32/STM32F1/libraries/RTClock/examples/RTCAdjust from the required code mentioned on the compiling page.

I am in the process of performing the calibrations, you have to let the device run for over a day to do this.

I wonder if the calibrations will fix the running issues or does the RTC only backup the time and it never runs in the background?

[retro16]

Maybe the RTCAdjust program will initialize your blue pill correctly, and then it will work with ACSI2STM. At least that's how I explain things.

Anyway, I found the potentially problematic line: acsi2stm/Devices.cpp:193: RTClock Devices::rtc;

Based on what you said, it should be: RTClock Devices::rtc(RTCSEL_LSE);

Not sure why I missed that. Anyway, can you test that change for me since I don't have the issue, and since I am on the move I can't really test. And when I'll be back my ST isn't setup at the moment anyway so I can't really test easily.

If calibration actually works, I will put it in the documentation, it's an important step.

Thanks a lot for your help !

[jfceklosky]

Yes I found that declaration in the source. I am away from my St at the moment as well. I will finish testing out the calibration first and check that it is keeping time.

Does the rtc run for you when disconnected from the blue pill and keep time correctly for your st? What st are you testing with?

[retro16]

I am testing on a 1040 STE. The other question, I'm not sure to understand what you mean, so sorry if I state the obvious or if I don't answer correctly.

The RTC runs on the blue pill, powered by the CR2032 battery. As long as there is a voltage applied on the Vbat pin (where the battery is connected), the clock will run and keep track of the current time, even disconnected from the ST or anything else. Calibrating helps with clock precision and drift. The blue pill integrates a standard 32.768kHz clock crystal for this task.

Atari ST models with no integrated RTC (which is the case of many models) don't keep track of the time so you have a small program that runs at boot to synchronize the ST's internal clock with the blue pill's RTC. This is done by the UltraSatan tools or the GemDrive hook driver.

[jfceklosky]

This all makes sense.

I just wanted to know if the unit you built is working as designed when it comes to the RTC, that's all.

The current acsi2stm code does need to be updated in the .ino setup() to use the 32kHz clock which I will test when I am back home. The default constructor in the RTC code which is what is being used does not use the 32hHz clock.

[retro16]

Yes, my 2 units behave correctly with my code, but I used blue pills that were already used with samples, so they might be already configured to work correctly. I don't know, that's surprising.

[retro16]

Should be fixed by 4.2a (still a prerelease because of the new PCB I still didn't receive and didn't test, but the code itself should be as stable as 4.10).

[jfceklosky]

Thanks for making the update on the RTC.

One question, should the rtc be initialized in the setup() function within the .ino file?

Also I just about have my github repos ready for the boards I created. Both use the original blue pill, but one is DB19 and the other is IDC20 (ultrasatan style).

[retro16]

No need to initialize in setup(), it should be fine as is. I checked with a new Blue Pill (including a full power cycle) and it worked right away. In fact, the RTC stays initialized because it runs on the CR2032 battery anyway.

About IDC20, I'm interested in that: I added one in my new "Compact" PCB but I'm not 100% sure about the pinout, I couldn't find any official documentation. I made some reverse engineering based on a few pictures and PCBs I could find, but no definitive documentation. Do you have good documentation about the exact pinout so I can double check ? Thanks.

[jfceklosky]

I will test out the new code on my existing board when I return from vacation, no ST with me here :(.

Here is my repo on the ICD-20. It is modeled after the official Ultrasatan that I own.

https://github.com/jfceklosky/idc2ribbon

The pin setup is a little odd seeing that it does not follow the pin numbering on the IDC.

Nice redesign on your compact version.

[jfceklosky]

Since I don't have access to an ST at the moment, I have been testing the Blue pill alone with the RTCAdjust example. The clock seems to be running fine when disconnected from USB power, but the VBAT hooked up.

I will retest my board with the updated code from the master branch and report back.

[Philsan69]

Tested firmware versions 4.2a and b. With ST turned off and PSU connected, my device's clock runs too fast. With ST turned off and PSU not connected, clock doesn't

[jfceklosky]

Running fast or slow can be a calibration issue. I am looking at the RTCAdjust example program here to do calibrations.

https://github.com/rogerclarkmelbourne/Arduino_STM32/tree/master/STM32F1/libraries/RTClock/examples/RTCAdjust

Silly question, do you have a battery hooked up?

[Philsan69]

Thanks for the reply! The clock runs very fast!

I think battery is hooked up, I'll replace it.

[jfceklosky]

The blue pill I am working with runs behind time wise when running on the battery.

I am using this one from Amazon: https://www.amazon.com/gp/product/B07VKSVM21/ref=ppx_yo_dt_b_asin_title_o05_s00?ie=UTF8&psc=1

[hayesey]

just to add to this, I also have the full size board that Philsan69 has. Initially with 4.10 on it but I cannot get 4.2b to work at all. I've tried upgrading using HDDFLASH from the ST and using a USB ttl cable. In either case the acsi2stm is simply not recognised by the ST when it boots. Reloading 4.10 again works fine.

However, my STfm has TOS 1.02 in it so I do suspect that could be the issue since 4.2b appears to work for Philsan69 and he is using the same board. I'm looking into upgrading to 1.04 TOS but it's not straight forward with an STfm with 2 chip ROM.

[Philsan69]

just to add to this, I also have the full size board that Philsan69 has. Initially with 4.10 on it but I cannot get 4.2b to work at all. I've tried upgrading using HDDFLASH from the ST and using a USB ttl cable. In either case the acsi2stm is simply not recognised by the ST when it boots. Reloading 4.10 again works fine.

However, my STfm has TOS 1.02 in it so I do suspect that could be the issue since 4.2b appears to work for Philsan69 and he is using the same board. I'm looking into upgrading to 1.04 TOS but it's not straight forward with an STfm with 2 chip ROM.

To upgrade firmware, did you press CAPITAL "Y" (SHIFT+y)?

EDIT You already know it ah ah!

[jfceklosky]

I am away from my ST at the moment, so I have not been able to test the 4.2b version yet. I do have a blue pill on one of my boards with the battery hooked up for RTC testing.

Just in case anyone is interested in an alt board setup. I created these:

https://github.com/jfceklosky/acsi2stm-alt-hardware

[Philsan69]

The blue pill I am working with runs behind time wise when running on the battery.

My device's clock is almost 50% faster (with ST turned on or ST off and PSU connected). At the moment I don't have a spare 2032 battery.

[hayesey]

To upgrade firmware, did you press CAPITAL "Y" (SHIFT+y)?

Yes I'm typing an upper case Y, it proceeds with the update, the ST reboots almost immediately. Also tried the upgrade with my ttl usb cable, I know that method works as it's what I originally used to install 4.10 and what I have used to reinstall 4.10 which is working again.

My device's clock is almost 50% faster (with ST turned on or ST off and PSU connected). At the moment I don't have a spare 2032 battery.

That seems very fast! Reading up on calibration of the rtc in the STM32, they're talking about drift of a few minutes per month. I've not tested mine yet, I can't really without using 4.2b which I suspect needs a TOS upgrade by me.

[retro16]

Hello,

This fast clock issue is very strange. Ideally it would be very interesting to probe the 32kHz oscillator to check its actual frequency (with a multimeter, oscilloscope or logic probe).

HDDFLASH is indeed super fast so it's not surprising to have an almost immediate reboot. Its only limitation is that it can't flash firmwares bigger than 64k (I can't recall if there is a size check, I suppose I implemented that correctly ... at least I hope).

4.2a/b should work exactly the same as 4.10 on any TOS between 1.00 and 2.06. If it doesn't, it's an ACSI2STM bug that deserves its own github issue ! 4.2b has changed the way it boots so a regression totally makes sense, but 4.2a is practically the same as 4.10.

[retro16]

Second message just to say that I will quickly post a 4.11 version based on 4.10 that only includes the RTC fix and nothing else. It's a one liner so it shouldn't take to long. Edit: done. It literally took me 10 minutes.

[hayesey]

This fast clock issue is very strange. Ideally it would be very interesting to probe the 32kHz oscillator to check its actual frequency (with a multimeter, oscilloscope or logic probe).

Yes that did occur to me too, I have an old oscilloscope so I'll try that tomorrow.

I'll give 4.11 a try now. I never tried 4.2a.

[hayesey]

Well, this is very odd. 4.11 doesn't work for me either. I've also noticed that the ones that aren't working for me (seemingly anything newer than 4.10), the green LED doesn't come on when the blue pill is rebooted with the jumper back in default position, with 4.10 it does and then goes off when I power on the ST.

Tried the upgrade to 4.11 using HDDFLASH, then using USB cable. Then reflashed 4.10 using USB and that's back working, 4.10 has never not worked for me!

It's clearly something specific to my setup, Philsan69 above has exactly the same board as me and 4.2a at least works for him.

Are there any differences in compile options between 4.10 & 4.11? I can see from the 4.11 commit that literally the only code change is the addition of the RTC parameter.

[Philsan69]

Updated to 4.11, thanks. Clock continues to run very fast (90 seconds instead of 60 seconds) and it doesn't run when PSU is not connected.

[jfceklosky]

I ran across this closed source product. It appears to be based on the STM32 aka Blue pill

https://sd4st.uk.to/

On their website they cover and provide a software for RTC calibration

https://sd4st.uk.to/documentation/rtc-calibration-procedure/ and https://sd4st.uk.to/documentation/rtc-technical-details/ and https://sd4st.uk.to/downloads/

[retro16]

@hayesey, could you please open another GitHub issue for your firmware upgrade problem ? I really want to understand what happened. Of course I will say the usual developer excluse "no no, I swear, I didn't change anything", but as a matter of fact something happened on my side and I don't want to ignore obscure issues anymore.

If you could also try the debug variant and check its output, that would be very appreciated.

I will try a few Blue Pills I still have in stock to see if all of them run at the correct speed. Maybe I have a bad one too, that would be interesting.

[hayesey]

I was holding off on doing that as I'm not convinced the issue is the software but since you asked I've raised the issue linked to above anyway.

[hayesey]

Aside from any other issues, it does seem that calibration of the RTC is mandatory if you want to keep the time accurate. Due to variances in different 32.768kHz crystals and even the temperature it's being used in.

There's some really good information here:

https://cool-web.de/arduino/interne-stm32-echtzeituhr-kalibrieren.htm

It's in German but translates well.

I notice that he found huge differences (from ~1 second per day to > 75 seconds per day) in the drift if the pins of the blue pill that are shared with the 32kHz crystal are connected to a breadboard. I can't see that being the case with the acsi2stm standard PCBs though as those pins are unconnected but worth thinking about if high levels of drift are seen.

I made a quick python version of his C example for working out calibration settings based on seconds of drift per 24 hour period:

import sys

secs_per_prl = 2.63671875
secs_per_rtccr = 0.0823974609375

secs_per_day_offset = float(sys.argv[1])

prl_offset = round((secs_per_day_offset / -secs_per_prl) + 0.99)

if prl_offset < 0: 
    prl_offset -= 1

prl_val = 32767 - prl_offset

rtccr_val = round((secs_per_day_offset + (prl_offset * secs_per_prl)) / secs_per_rtccr + 0.5)

print("PRL offset is: ", prl_offset)
print("PRL register value is: ", prl_val)
print("RTCCR register value is: ", rtccr_val)

It is technically possible to calibrate for a 50% difference (43200 seconds per 24 hours) but from what I understand that means the crystal is running way too fast which seems odd. I will test mine with my scope though when I get a chance to.

So then perhaps some code can be added to acsi2stm to load a drift value from the SD card on boot up and apply the calibration? Or maybe even provide a TOS program to do it like that sd4st project (sadly closed source) does.

[jfceklosky]

Thanks for the script. I have been working the the RTCadjust program that is supposed to do the same.

I am curious, Did you try the software from the sd4st for the calibration setting? I wonder if it will work.

Here is the location: https://sd4st.uk.to/downloads/

There is an sd4st_util to download that has the TOS program.

[hayesey]

I haven't tried it, I assume it needs the matching hooks in the STM32 firmware to do anything?

[jfceklosky]

No harm is testing the sd4st software on the ST.

I will try it but I am away from an ST for a few more days.

[Philsan69]

Changed battery and now clock keeps the date. Moreover, when connected to PSU, instead of being 50% faster (with empty battery), now it's 6% slower.

[retro16]

Implementing calibration in the STM32 is technically possible ... if you can do that in less than 200 bytes because I'm out of flash memory (I want to keep the debug variant under 64k). The other solution is to stop using the less-than-optimal 32k oscillator of blue pills. I chose a quartz that announces a 20ppm precision on the (still not tested) compact PCB so this shouldn't require calibration. You don't need to calibrate a $3 watch, so it shouldn't be too difficult to find a good enough quartz that doesn't require calibration.

These 50%/double speed behaviors look like either uninitialized STM32 registers that take random values (in that case, a RTClock library bug) or a transient hardware fault (oscillator locking on a harmonic of the quartz)

[hayesey]

Changed battery and now clock keeps the date. Moreover, when connected to PSU, instead of being 50% faster (with empty battery), now it's 6% slower.

What are the specs of the power supply you're using? The battery you originally had was brand new and from Farnell in the UK (a huge electronics distributor so not some junk from Amazon).

I haven't had a chance to do any more testing or experimentation yet, it'll probably be next week now as I'm away for a few days tomorrow.

[Philsan69]

Tested original battery with multimeter and it's OK. I installed it again and now time is saved. Don't know why it wasn't working before.

Now clock with computer on is 18% slower. With other battery it was 5% slower. With computer turned off clock lost only 22 seconds in 26 minutes.

[jfceklosky]

Which version of the firmware are you using?
The one with the RTC clock fix?

[Philsan69]

Which version of the firmware are you using? The one with the RTC clock fix?

Yes, 4.11

[jfceklosky]

Back home with my ST again! I just tested one of my boards with the 4.11 firmware. The clock is now running when disconnected from the USB power source (with the battery in place).

Thanks for all of the advice and support working to correct this.

NOTE: I was retesting with a Blue Pill that I was running the RTCAdjust program on prior to flashing with 4.11.

I will take a brand new Blue Pill and just start with 4.11, see what happens, and report my findings

[hayesey]

Tested original battery with multimeter and it's OK. I installed it again and now time is saved. Don't know why it wasn't working before.

Now clock with computer on is 18% slower. With other battery it was 5% slower. With computer turned off clock lost only 22 seconds in 26 minutes.

what voltages do you see from both batteries?

I'll do some testing on mine tonight.

[jfceklosky]

I measured the voltage at VBAT and ground with battery installed and USB not plugged in:

3.22 volts

[retro16]

This really looks like an uninitialized register. The cheapest quartz wall clocks run very precisely independently from voltage. Most crystals easily reach 50ppm precision if not better, it shouldn't require any kind of calibration - calibration is supposed to be only for the internal RC oscillator.

[jfceklosky]

I will test with a new blue pill and report out. I just ordered a batch of new boards for builds that I will sell.

The one I updated to 4.11 has been running the clock fine off of the battery when usb power has been disconnected.

[jfceklosky]

Testing again..

I took a brand new one of these: https://www.amazon.com/gp/product/B0B3X4BH4Q/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&th=1

and flashed with version 4.11 (used the same Gigastone SD card that I have been testing with an HD image on it)

Did the following:

• booted the STe. It saw the device and the HD image
• set the time using us_setcl from Jookie and ran us_getcl to get the time just set
• pulled the USB power from the device (CR2032 was installed on the board hooked to VBAT)
• waited 5 minutes and then pulled the USB power back in

• Booted the STe and ran us_getcl...the clock reported 5 minutes later

  I would call the changes made in 4.11 around the clock a success!

I will leave the USB power unplugged for a longer period and check the time too.

[jfceklosky]

After about 12 hours only running the clock on battery, the clock is keeping time very well!