@yatli There was a lot of back and forth here, what is the Vbatt mod, how do you do it, and what do you gain from it?
The keyboard mcu stm32f103 has internal RTC functionality. The RTC module can be powered independently with a battery via the VBAT pin, but unfortunately, picocalc board directly connects that to system 3v3 (Keyboard/BIOS feature+bugfix wishlist - #36 by yatli). So I cut the trace from 3V3 to VBAT and hooked up a coin battery instead (Keyboard/BIOS feature+bugfix wishlist - #38 by yatli).
Is the RTC functionality accurate?
what do you mean by accurate? like, time drift?
The RTC section has its own crystal, factory calibrated. So I guess it should be on par with external chips?
1 Like
Let me get this straight. The stm32 has all that and the only thing missing is a header to a coin cell?
1 Like
There is a risk of reverse current going into the coin cell (Keyboard/BIOS feature+bugfix wishlist - #37 by JackCarterSmith)
I connected a battery directly. “I’ll do the diode thing later” 
1 Like
Thanks for the time to review it!
For the battery question: this return is only for I2C “global” failure during runtime. If I2C work, we should not get into this return. (I wanted to handle the I2C failure case someway but for now it’s only “blink the LED” to notice the user, instead of auto-reset through watchdog).
To be sure of the “compatibilities”, the common registers need to be at the same address. But I think I’ve found an effective compromise thanks to pelrun’s comments.
I got the idea using CRC instead of hardcoded ID for the EEPROM. But finally didn’t added it, not a priority given the importance of the parameters.
However, I just noticed that I didn’t add a clamp when reading from the EEPROM… This could lead to something not very good.
I forget a precision about STM32 RTC, a “big” issue in some case: when the STM32 do a reset, the ST HAL do a reset of the RTC during periph init… I need to create a “dummy” init (MX_RTC_Init2) to avoid the reset from the “official” driver.
After one month leaving the pico with the RTC, I only show one minute drift from my ref (NTC server). I think pretty good due to the usage of the external crystal!
3 Likes
4 weeks, 4 seconds fast (without additional calibration, coming soon). DS3231 with temperature compensated crystal.
2 Likes
After fixing the RTC date of the firmware I noticed bad news:
- the RTC doesn’t remember the date (is only a “nice” 32-bit counters)
- After one day and one hour, the counter “lose” the 24 hours?!
So… For all the issues have mentionned in the custom firmware post, plus the RTC now… Just annoying, 10 years old design…
I just got curious about “replacement” part. And I found the perfect candidate for that experience 
!
Hello STM32F401RC!
A real RTC (w/ hardware calendar), FPU, switch to bootloader from firmware, 256 kB of flash, not so much power usage than the F103 and pins compatible! For just $5 + shipping…
Sound overkilled… But who cares?!
4 Likes
is it pin compatible? would it be drop-in? if no board changes are necessary, i think a few niche freaks might be interested… 
Pin compatible yes but needs experience removing and soldering surface mount components, not for the light hearted. Peter did a blog about it over on the Backshed… Makes you wonder why bother tho when we have the accurate DS3231 compatible with MMBasic.
1 Like
I’ve ordered it, so if I missed something during the comparison of pins, I’ll get the answer soon!
The only thing who “should” not work, is the bootloader switch from software (because the SEL-1 switch both the boot0 pin AND the serial bus from the pico to the stm32…).
Only way to handle things will be to add a DFU mode on the USB interface, and put on the SEL-2 switch).
The presence of the memory mapper, in addition to the software switch to switch between the bootloader and the app, should allow other firmware to be dynamically loaded onto the same STM32.
But you must be very careful not to reset the GPIOs during the operation, or the PMIC may be reset. Check the idle states of the pins (if reset state = Vdd, you’re good).
I’ll probably recommend the advice from @DigitalDreams to use a DS3231, as the “news” features are still some dreams in our heads for the moment…
Fortunately, the STM32 is not BGA, but it is not within everyone’s reach.
Still, the custom firmware shouldn’t evolve much from my side, only making compatibility with the official firmware, I dropped the wake-up feature by RTC from this one.
EDIT:
I didn’t noticed one pin in bottom right corner… the I2C aren’t available x)
Bad thing to take a decision when you needed to sleep!
Can be possible… But need some cutting and add caps… Absolutly not for beginners!
In that case, I’m leaning towards your always-on solution.
When pico is shut down, stm32 can go into deep sleep. We then set up a wake up timer so that it periodically calibrates the datetime in RTC custom registers (and zeros the buggy RTC timer so that it never overflows).
The datasheet (XPowersLib/datasheet/AXP2101_Datasheet_V1.0_en.pdf at master · lewisxhe/XPowersLib · GitHub) states that power key long press period can be customized so we can set a super long (10s for example) value.
Then, we can expose the power key as a normal physical key with the additional functionality that it can wake up the southbridge from deep sleep.
In fact, only the 405 series is “ok” with only exception to do some “hack” on 2 power pins (add 2 caps between pin and pad). Like the Figure 1 of my previous post show.
I’ll try further with the STM32F405RG before making an another order. I think you already got in mind, but the replacement procedure will be more picky than “just” desolder-resolder.
I plan to lift the VSS pins up, and place a 0402 caps between them and their pad. I didn’t fully read if the VSS caps are decoupling ones or for power filtering however… (high chance there are the 2nd option)
@yatli Not sure if I fully understand your understanding 
Actually this is the current default behavior: when the pico ask “shutdown” OR the power is “long pressed” (and already on), the pico is shutdown (as well of the audio amp stage) and the stm32 go to sleep. One pressing on the button or RTC alarm trigger will wake-up the sleepy chip and handle things from here…
My goal was to set a date for an alarm (in 1, 5 or 20 days for exemple) or simply a daily one at 6 am…But after some experiments, I noticed:
- there is only one alarm available, so only one alarm trigger can be active at one time,
- for the 25 hours overflow, I’m not sure about it… From my estimation, the overflow shouldn’t occurs before 36h. So you got in theory 12 hours after 24 to do the date update in software.
I’ve implemented a “patch” which do the date update when the stm32 wake-up (from alarm or pwr button pressing). Maybe it glitch sometimes due to the behavior of the HAL driver who want to reset everything by default (F1 series is the cursed one), I needed to do some “ugly” stuffs to compensate…
So some further investigation is needed before choosing a proper solution for the date update.
In any case, we need to wake-up on a daily basis to update date somehow. As I already save alarm date in SRAM, I thought of infinitly reset the alarm (only if the alarm date > current date) to the next day until we reach the correct alarm date… Heavy in the concept but should reach a lot of use corners.
I really wish clockwork would release the PCB so the community could create variations.
3 Likes
A full parts list and prices with delivery in 2 weeks max 
1 Like
Not hard to beat the record of delivery 
2 Likes