acsi2stm
acsi2stm copied to clipboard
retro16
RTC not advancing when USB power disconnected
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:
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
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
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.
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?
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 !
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?
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.
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.
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.
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).
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).
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.
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.
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.
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
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?
Thanks for the reply! The clock runs very fast!
I think battery is hooked up, I'll replace it.
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
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.
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!
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
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.
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.
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.
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.
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.
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.
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.
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/
@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.