For the second time since first breath some months ago my PicoCalc had a headache.
The first time weird things suddenly started showing at the cursor when i pressed any key. Just now it happened again, EVERY key did a backspace !. Luckily I had just saved my growing program !
Must be some kind of STM32 crash, powering off and on always cleared it and is always fine after.
The moral of this tale, SAVE YOUR PROGRAM FREQUENTLY. I always save twice, second one as ‘.bak’. I also backup the SD card to my PC every few days (changed programs only).
As I take a look on the keyboard driver (on the STM32) its lack of checks on start…
What I can say is if just one bit start high, you can have this kind of glitch, without being noticed, until you fully power reset.
Your behavior seem validate my analyze.
That’s how “stable” the STM32 is!
(I don’t want to put some ads, but since you use the keyboard frequently, you could try my custom firmware and see if you still experience this “slow” glitch or not. What I can be sure of is that there are no duplicates key press on it.)
Battery -129% ! (yes minus). No keys responding so had to hold power off. Switched back on and all fine (battery reporting 100%). Issues occur around once every 2-4 weeks. And yes for the observant, Pico2 overclocked to 378Mhz but cool and stable (with heatsink) 99% of the time….
I couldn’t tell by your posts what version of the STM32 bios/firmware you’re running. Probably a good idea to at least upgrade it to the official 1.4 version that dropped a few weeks (or maybe months, I forget) ago. It’s not as optimized as the custom one, but it fixes some bugs and is probably more stable than previous versions. I haven’t noticed the weird battery thing with it, but I may have missed it is as I rarely check the battery and only see it when I power on the device and have it printed at startup.
JackCarterSmith’s custom firmware is great too, and although it had a problem with keyboard key detection at startup that affected the U2F Loader which caused me to switch back to 1.4, that’s fixed now and I plan to flash it back on my device again the next time I have a reason to open up the case. (Even with the screen taped down and no damage since the replacement, I’m still wary of opening the case very often).
There’s no changelog that I’m aware of, but the commit history shows the changes. I’m not sure how far back the 1.4 changes go though but I guess it might be possible to figure out by comparing dates. The battery reporting issue you identified seems to have been fixed in the April 21st commit, which I’m pretty sure wasn’t included until 1.4.
A little farther back there is a code change related to the backlight which might be the reason I could never get that working properly from PicoMite. I’ve got 1.4 installed now though so I’ll try that again. Recently went down a rabbit hole looking into changes in the latest PicoMite updates that increase display update speed while reducing color depth. They supposedly support the display we’ve been using on PicoCalc, but when I switched to try the new code I only get a black screen, so maybe the display on PicoCalc doesn’t exactly match that one after all, and is just close enough for it to work with the old code.
I haven’t encountered this bug either on my end.
If you said none the keyboard or the power button does something in this state, maybe the overclocking of your Pico2 made the I2C bus unstable/glitched on your picocalc?
The official firmware use an uncommon 10 kHz frequency for the I2C bus with the STM32, I can’t change it without breaking the compatibility. And if the I2C get stuck, it doesn’t reset itself without a power reset (something I’ve managed on mine combining re-arm timeout and watchdog for the worst case of hardware stucking).
You can try to disable the overclock for a moment, check if the bug reappears?
Yes I’m aware it’s running slow at 10Khz, they must have encountered issues for some reason. Downclocking isn’t an option as the problem only occurs every 2-4 weeks and doesn’t return for the same so would take weeks to see if the issue happens at say 150Mhz. I might be clocking even higher than 378Mhz soon once a heatsink is finished, that might reveal something !
Look very strange, -129 can only be written with 9 bits at least (0xFF0F in uint16)… Sounded like you’re reading an inverted signal (or an oversampled one too).
As you are far away of the specs from RP2350 datasheet, we can’t be sure that all peripherals run fully stable without any glitchs.
Did you plan to cook eggs on it?
At least, if you get much often this glitch with an higher freq, that can prove this assumption!
Thermal isn’t the only limit of the max frequency of a circuit. The configuration of the transistors inside create a logical limit (called critical frequency or path), after what the circuit doesn’t produce the expected behavior.
. Any changelog posted anywhere ?
.