By any chance is there a known issue where the keyboard becomes entirely unresponsive until you reset it with SHIFT+power long press? Sometimes I have to reboot multiple times.
I’ve been fighting this and am really annoyed with it.
Might also be my keyboard being broken, no real idea what is causing it.
@Kuratius Sorry for the delayed answer…
Indeed, it’s a know bug and related to "how” the stm32/keyboard chip handle the message from the pico. To be short: any incomplete/malformed request could hold the keyboard.
My initial approach was to reset the driver after a short period of time (less than 500 ms), but it’s possible that I didn’t implement it fully.
I can assure you that this is one of my goals for 1.0. However, I can’t say when it will be implemented.
I’m hopeful we’ll have it wrapped up this year, though.
@Kuratius Thanks to your “bug report”, and after some digging, I found few garbage poorly implemented code in the I2C driver on my side.
Really sorry to let a so much bugged version for a long times…
To make amends for that, I worked on a fix and reworked the I2C implementation. I can confirm that the 100 kHz setting works on my end, and the keyboard no longer freezes due to the faulty I2C.
https://git.jcsmith.fr/jackcartersmith/picocalc_BIOS/releases/tag/v0.9
I should have patched the issue with the power button too. @BrianO
Let me know if you encounter the same bugs again.
@JackCarterSmith I loaded 0.9 onto my PicoCalc and it works!
It would be great if you and @ernst worked together to produce the best BIOS for this device. Right now it’s not clear which BIOS we should be using.
Thanks for your work Jack! ….. Brian
Glad its work properly for you too!
If I’m not mistaken, Ernst patched the official BIOS. It was even re-added to the official GitHub repository 2–3 weeks ago.
But for my part, I’m proposing a reworked version that uses only the ST library and the ARM toolchain. After all, it was the “st-duino” overhead that I originally wanted to remove, adding the RTC and reducing power consumption.
To answer your question, I don’t think we should “force” a user to use a particular firmware.
But to help you decide, what I can say is that if you want to use the built-in RTC without making any hardware changes, reduce overall power consumption, or take advantage of the ability to save backlight and keyboard settings, then this BIOS might be of interest to you; otherwise, the official/Ernst’s BIOS is sufficient.
@JackCarterSmith I’ve been using your 0.9 BIOS, and noticed occasionally the power LED blinks briefly. Is that significant of something going on in the Pico? thx….Brian
@BrianO Indeed, It’s normal, I keep a debug code to blink led when the I2C driver is “refresh” due to any error or timeout on the I2C bus.
Could you say, in average, how much often this blink occurs and the frequency you use for the I2C?
Dear @JackCarterSmith, I’ve just installed your 0.9 firmware version and the good news is that it now works with a Luckfox Lyra running Calculinux.
Unfortunately, what isn’t working properly is shutting down using `shutdown -h now`. Although the system shuts down and the Luckfox Lyra powers off, the green power LED and the keyboard light remain on. Only when I hold down the power button for 2 seconds also the motherboard shuts down.
Do you have any idea what might be causing this?
@Codiator Thanks for the feedback!
Mmm… Sound like the southbridge doesn’t understand (or receive) the shutdown update.
The correct register is at 0x0E:
Bit 5:0 => time in sec before stop/sleep,
Bit 6 => set to 1 to go in sleep,
Bit 7 => set to 1 to full power off.
Maybe the bit 7 who mess with your setup. The official firmware doesn’t need a bit to select between full power off or sleep…
You can write “0x80 | stop_delay” in the register to power off, or 0x40 to go to sleep. This will want affect the official firmware…
I’ll think about that, a simple write should be sufficient to trigger, and the 7th bit value to select between power off type.
EDIT: I remember the “why”: the stm32 needed to know when I requested a poweroff, I choosen to keep a dedicated bit (one for both power off and sleep) in the register for simplicity.
Thanks @JackCarterSmith .
While playing some games I notice it randomly. Maybe on average once every 20 minutes or so. I have not changed any of the frequencies from the default…..Brian
@BrianO In this case, I suppose the I2C frequency should be 10 kHz, so clock stretching does its work. But in some case, I noticed the stretching can fail sometime, but the firmware detect it and proceed to a reset (only the I2C peripheral, not the picocalc, that’s why I added the indicator light so I’d “know” when it happened).
I should recommend to switch to 100 kHz, as it the default standard for I2C. I suppose the last version of the official firmware support it well now (in fact, just 2 days ago).
@Codiator I come with the idea to “force” set the full power-off bit if none are set when writing to avoid breaking both the official behavior and the I2C slave on my side.
It will be added in the next release (hopefully the glorious 1.0! :3).
Just keep in mind that, unlike the official firmware, I didn’t clamp the delay to 6s, you can request a delay of 10s, 20s or whatever between 0 and 63s.
How do I switch to 100kHz? How do I switch back to the default speed?….Brian
If you’re using MMBasic, I suppose the command is OPTION SYSTEM I2C SLOW? (I didn’t use MMBasic so maybe this information is out of date)
But if you’re using the C/Pico-SDK, the function is i2c_init(i2c1, 100000);
Correct. Every version I supplied and the latest official (TBS) versions:
OPTION SYSTEM I2C SLOW --> 100Khz (default)
OPTION SYSTEM I2C FAST --> 400Khz
This option command will cause a restart.
I entered OPTION SYS”TEM I2C FAST
the pico rebooted, not the keyboard does not respond.
Press-hold power button does not power off the device.
Pulled batteries & replaced…power up. Could type a few keys then froze again.
Press-hold power turned off power. Power on…keyboard does not respond.
How do I put it back? Do I need to reload the BIOS code?
Option 1) Nuke the flash and then flash PicoMite uf2
Option 2) Connect the MicroUSB port on the Pico to a computer and use a terminal emulator to access the serial console to reset the option.
Tried option 1:
After clearing then reloading picomite, when I powered on, the LED lit green, and keyboard light went on, bot nothing on the screen.
Didn’t try option 2.
I reloaded BIOS 1.6 and all is working normal again.
Thank you!…..brian
Unfortunately, I couldn’t reach 400 kHz without causing the STM32 to crash (the lack of debug access doesn’t help too). Only 100 kHz is safe for now.
I’m still looking into what I can do about this, but it’s not a priority.