Custom PicoCalc BIOS/keyboard firmware

PicoCalc
, ,
1

Hi everyone,

I redesigned the original STM32 firmware of the picocalc (aka “BIOS” or keyboard driver) to better suit my needs.
A brief overview of the differences:

  • persistent saving of settings like backlight,
  • internal use of the RTC and wake-up from it,
  • drastic reduction in static power consumption,
  • …

Here is the source https://git.jcsmith.fr/jackcartersmith/picocalc_BIOS and the binary firmware for flashing.

Please note that this is a pre-release version, so I haven’t tested it much yet. There may be hidden bugs…
But if you want to try it and give me a feedback, it’s always appreciated!
In this case, I recommend reading the rest of this post.

=== Technical details ===

The settings of the backlight are saved inside the STM32 chip 1.5s after the last value change. Saved settings are keep between restart and further firmware upgrade. The only way to clear it is by erasing the full flash.
The brightness curve has also been revised.

A new TYPE register (addr = 0x00) have been added to identify custom firmware, as the official firmware will always answer 0x00 when accessed.
This custom firmware use the TYPE-ID 0xCA.
You can use this register to test what kind of firmware is running on your stm32 and set the corresponding registers table (I’ll push a driver exemple in time with the v1 release, and possibly a pull-request on the legacy driver of the picocalc repo to be used in picomite or others projects).

I made some change in the backlight value range, this only change from raw 8-bit value to 10 steps [0-9]. This only impact from you if you drive the backlight from the pico.

RTC interface have been implemented since v0.5, actually need more deep sturdiness testing.

The power manager has also been further developed: the AXP2101 PMU is no longer stopped but the STM32 is put to a “sleep” state when the picocalc is stopped. It’s mandatory for the RTC to work. This mode has overall consumption <0.1 mA. And in the event of a fault or low battery level, it switches everything off.

Normally, all official registers are operational. With the exception of the management of external interrupts, which is currently being written… WIP

It’s forked from the 1.2 official firmware.
I’ve used the STM32 HAL and CMSIS lib to reduce the firmware size and allow more features in the futures.

=== Important notes ===

That’s for me like an “alternative”, not a replacement!
After careful consideration, I do not plan to ensure compatibility with the original firmware.
But still free to pick some parts or all the stuff for your projects.
I am still planning to provide a replacement i2ckbd driver that will work with this firmware and the original firmware.

Hack’n Play!

9 Likes
2

This is really cool. So the goal is to retrieve RTC values from I2c?

3

I didn’t read the source, but we need to come up with a way of probing the stm32 firmware version from the pico in order to adjust behavior. Maybe someone could come up with a scheme which includes a vendor id and version number (like usb?)

4

Hi, great and clean rewrite, here some suggestions

Feature requests:

  1. Power button
    send 0x74 send via FIFO for power button should be availabel from PMU
  2. IRQ for keyboard events instead of i2c constant polling, will save a lot of CPU(power) we can use pins from spare second UART already connected to stm32 and pico. Second pin fro rtc?
  3. i2c command for pico reset via pins (kinda power reset for pico)
  4. i2c command for full power shutdown
5

Yes, I planned to implement it when I’ve finished polishing the registers that already exist but are not implemented on the logic side (such as keyboard config, debounce time, etc.).

For that point, I wanted to use the REG_ID_VER… However, it’s only 8-bit long and I don’t want to “lock” 2 or 3 bits just to separate the custom versions between them.
I was thinking of adding a new REG_ID_TYP register, by default it would return 0 on the original firmware and another value for all other custom versions. In this way, the REG_ID_VER register will continue to serve as the version register, without any interference from ‘firmware provenance’.
And this is more or less in line with your USB ID idea…

Thanks for the feedback too!

  1. Somethink to reset the pico with power button you mean? I saw @pkr implement something like this too.
  2. Yes… I’ve lost some hairs showing this I2C protocol, not so bad but definitely not the most effective… I want to add this kind of IRQ-request logic as an overlay to keep the old polling method available for compatibility.
  3. And 4. Like “reset-me” and “shutdown” command? Sound good! Normally, there is a REG_ID_RST register for the reset, but I suppose I’m going to separate the reset of the stm32 from the pico, because a “full” reset of the STM32 also results in a reset of the pico…
6
  1. Power button attached to the PMU can trigger event like long press for default poweroff and poweron, but also for short press on power button, the idea to send this event as usual keyboard key to the fifo with 0x74 code(power button code on linux) so software on the pico can for example handle it and go to sleep/ switch screen turn on or turn off.
  2. Yes it’s already present in protocol, there is a FIFO count cmd in i2c and southbridge can trigger interrupt on the pico pin, then pico will ask i2c for fifo count and read the amount of fifo messages and drain the FIFO, then just read fifo as usual for key codes.
  3. So there are will be 3 resets and 1 poweroff command:
  • Reset the Pico enable pin (power cycle the Pico)
  • Reset the STM32 without losing power on Pico if it’s possible (software or power cycle)
  • Power cycle reset for STM32 and the Pico (remember old reset button on PC )
  • Power shutdown for all power lines(via PMU shutdown) (Like long press power button)
    In this case we can issue this commands to fully control the power sequence of the PicoCalc device. Instead of just soft reset the pico in the code.

Also since we use 1 bit for read write access, we left with 7 bits for commands so we can have 128 general commands

|  Hex | Dec | Notes             |
| ---: | --: | :---------------- |
| 0x00 |   0 | (Free / Reserved) |
| 0x01 |   1 | (Free / Reserved) |
| 0x02 |   2 | (Free / Reserved) |
| 0x03 |   3 | (Free / Reserved) |
| 0x04 |   4 | (Free / Reserved) |
| 0x05 |   5 | (Free / Reserved) |
| 0x06 |   6 | (Free / Reserved) |
| 0x07 |   7 | (Free / Reserved) |
| 0x08 |   8 | (Free / Reserved) |
| 0x09 |   9 | (Free / Reserved) |
| 0x0A |  10 | (Free / Reserved) |
| 0x0B |  11 | (Free / Reserved) |
| 0x0C |  12 | (Free / Reserved) |
| 0x0D |  13 | (Free / Reserved) |
| 0x0E |  14 | (Free / Reserved) |
| 0x0F |  15 | (Free / Reserved) |
| 0x10 |  16 | (Free / Reserved) |
| 0x11 |  17 | (Free / Reserved) |
| 0x12 |  18 | (Free / Reserved) |
| 0x13 |  19 | (Free / Reserved) |
| 0x14 |  20 | (Free / Reserved) |
| 0x15 |  21 | (Free / Reserved) |
| 0x16 |  22 | (Free / Reserved) |
| 0x17 |  23 | (Free / Reserved) |
| 0x18 |  24 | (Free / Reserved) |
| 0x19 |  25 | (Free / Reserved) |
| 0x1A |  26 | (Free / Reserved) |
| 0x1B |  27 | (Free / Reserved) |
| 0x1C |  28 | (Free / Reserved) |
| 0x1D |  29 | (Free / Reserved) |
| 0x1E |  30 | (Free / Reserved) |
| 0x1F |  31 | (Free / Reserved) |
| 0x20 |  32 | (Free / Reserved) |
| 0x21 |  33 | (Free / Reserved) |
| 0x22 |  34 | (Free / Reserved) |
| 0x23 |  35 | (Free / Reserved) |
| 0x24 |  36 | (Free / Reserved) |
| 0x25 |  37 | (Free / Reserved) |
| 0x26 |  38 | (Free / Reserved) |
| 0x27 |  39 | (Free / Reserved) |
| 0x28 |  40 | (Free / Reserved) |
| 0x29 |  41 | (Free / Reserved) |
| 0x2A |  42 | (Free / Reserved) |
| 0x2B |  43 | (Free / Reserved) |
| 0x2C |  44 | (Free / Reserved) |
| 0x2D |  45 | (Free / Reserved) |
| 0x2E |  46 | (Free / Reserved) |
| 0x2F |  47 | (Free / Reserved) |
| 0x30 |  48 | (Free / Reserved) |
| 0x31 |  49 | (Free / Reserved) |
| 0x32 |  50 | (Free / Reserved) |
| 0x33 |  51 | (Free / Reserved) |
| 0x34 |  52 | (Free / Reserved) |
| 0x35 |  53 | (Free / Reserved) |
| 0x36 |  54 | (Free / Reserved) |
| 0x37 |  55 | (Free / Reserved) |
| 0x38 |  56 | (Free / Reserved) |
| 0x39 |  57 | (Free / Reserved) |
| 0x3A |  58 | (Free / Reserved) |
| 0x3B |  59 | (Free / Reserved) |
| 0x3C |  60 | (Free / Reserved) |
| 0x3D |  61 | (Free / Reserved) |
| 0x3E |  62 | (Free / Reserved) |
| 0x3F |  63 | (Free / Reserved) |
| 0x40 |  64 | (Free / Reserved) |
| 0x41 |  65 | (Free / Reserved) |
| 0x42 |  66 | (Free / Reserved) |
| 0x43 |  67 | (Free / Reserved) |
| 0x44 |  68 | (Free / Reserved) |
| 0x45 |  69 | (Free / Reserved) |
| 0x46 |  70 | (Free / Reserved) |
| 0x47 |  71 | (Free / Reserved) |
| 0x48 |  72 | (Free / Reserved) |
| 0x49 |  73 | (Free / Reserved) |
| 0x4A |  74 | (Free / Reserved) |
| 0x4B |  75 | (Free / Reserved) |
| 0x4C |  76 | (Free / Reserved) |
| 0x4D |  77 | (Free / Reserved) |
| 0x4E |  78 | (Free / Reserved) |
| 0x4F |  79 | (Free / Reserved) |
| 0x50 |  80 | (Free / Reserved) |
| 0x51 |  81 | (Free / Reserved) |
| 0x52 |  82 | (Free / Reserved) |
| 0x53 |  83 | (Free / Reserved) |
| 0x54 |  84 | (Free / Reserved) |
| 0x55 |  85 | (Free / Reserved) |
| 0x56 |  86 | (Free / Reserved) |
| 0x57 |  87 | (Free / Reserved) |
| 0x58 |  88 | (Free / Reserved) |
| 0x59 |  89 | (Free / Reserved) |
| 0x5A |  90 | (Free / Reserved) |
| 0x5B |  91 | (Free / Reserved) |
| 0x5C |  92 | (Free / Reserved) |
| 0x5D |  93 | (Free / Reserved) |
| 0x5E |  94 | (Free / Reserved) |
| 0x5F |  95 | (Free / Reserved) |
| 0x60 |  96 | (Free / Reserved) |
| 0x61 |  97 | (Free / Reserved) |
| 0x62 |  98 | (Free / Reserved) |
| 0x63 |  99 | (Free / Reserved) |
| 0x64 | 100 | (Free / Reserved) |
| 0x65 | 101 | (Free / Reserved) |
| 0x66 | 102 | (Free / Reserved) |
| 0x67 | 103 | (Free / Reserved) |
| 0x68 | 104 | (Free / Reserved) |
| 0x69 | 105 | (Free / Reserved) |
| 0x6A | 106 | (Free / Reserved) |
| 0x6B | 107 | (Free / Reserved) |
| 0x6C | 108 | (Free / Reserved) |
| 0x6D | 109 | (Free / Reserved) |
| 0x6E | 110 | (Free / Reserved) |
| 0x6F | 111 | (Free / Reserved) |
| 0x70 | 112 | (Free / Reserved) |
| 0x71 | 113 | (Free / Reserved) |
| 0x72 | 114 | (Free / Reserved) |
| 0x73 | 115 | (Free / Reserved) |
| 0x74 | 116 | (Free / Reserved) |
| 0x75 | 117 | (Free / Reserved) |
| 0x76 | 118 | (Free / Reserved) |
| 0x77 | 119 | (Free / Reserved) |
| 0x78 | 120 | (Free / Reserved) |
| 0x79 | 121 | (Free / Reserved) |
| 0x7A | 122 | (Free / Reserved) |
| 0x7B | 123 | (Free / Reserved) |
| 0x7C | 124 | (Free / Reserved) |
| 0x7D | 125 | (Free / Reserved) |
| 0x7E | 126 | (Free / Reserved) |
| 0x7F | 127 | (Free / Reserved) |

For example reset command second byte can address what device should be reset so we can do any of 3 resets via one write command and bits set for the cmd param
I could also help with RTC cmd, to set alarms for wakeup if we put Pico in sleep mode.

As for the 2 pins connected between pico and stm32, first pin just to trigger keyboard interrupt and the second pin attach to interrupts for all other southbridge events. So if pico triggered by the second pin it issue the i2c command to ask for event, end events could be done via the FIFO or just one event stored in register to read.

PS I know it’s looks a little bit complicated but it gives so much flexibility and power for the pico firmware.

7

Great explanation!

For the 1. point, I’ll probably call this mode “stand-by” from now, as it’s very similar to pressing the power button on a PC to put it to sleep.

The pico pin to be used seem to be the issue for me right now, the only connections between the pico board and the stm32 are the I2C and the UART bus.
As I didn’t plan to use this UART, I was thinking of reconditioning it as IRQ_pin… And can only be de-asserted by reading the IRQ registers/FIFO. (I’d better start documenting these things or I’ll end up getting lost in thought :P)
Btw, the official firmware have a draft for that feature, but not implemented in final (probably because there is no program space left…).

The power commands seem good for me, except for this one:
“Reset the STM32 without losing power on Pico if it’s possible (software or power cycle)”.
Because of the electronic design, I cannot carry out a complete reset of the stm32 core without resetting the pico by domino effect. The best I can do in this context is to reset the registers, re-init the I2C and clean the FIFO.

And the power shutdown (actually the only mode implemented), look for the long press power button, and trig the PMU/PMIC shutdown directly, without waiting ACK from the pico (because this require a software implementation of that on the pico firmware).
But to this last point, we can add a configuration option in the correct register (REG_ID_CFG), by default it isn’t enabled, to wait for an ACK from a compliant pico software.
If the pico software support this feature, at the boot step, it configure the stm32 with this configuration option. In case of long press trigger, the STM32 send the IRQ, wait for ACK from the pico, and do the shutdown request to the PMIC.

For the moment, my current roadmap is as follows:

  • Missing official registers
  • RTC (+docs)
  • I2C IRQ mode (+docs)
  • Power modes (+docs)

EDIT: I made a misstake maybe, it should be possible to reset the STM32 without interfering with pico, need testing…

1 Like
8

Also try to check if there is more flash in the stm32, I see somewhere if it stated as 64kb, there can be 128kb. So double the size.

9

ST is unclear about the flash size, after crossing every datas (expecially the Ordering information scheme in the datasheet) and testing on the chip (STM32F103R8T6), I’m sure it’s a 64KB version.

10

I’m just starting to play around with picocalc development, and having to unplug the usb cable, hold down BOOTSEL, and plug it back in again is getting old (and I only get to do it so many times before something breaks).

Is it possible for the keyboard driver to put the machine in BOOTSEL mode with some particular keypress? That would be really handy if it was done by the stm32 so that it’s always available.

-Dave

11

Technically yes, but only with hardware mods. It’s better/easier to to put it into flashing mode from the pico itself via software, such as with machine.bootloader() in micropython

1 Like
12

I had wanted to implement a switch to the bootloader in software, but this option doesn’t seem to be possible on this family of chips (F10xxx)…
The only others solutions would be a hardware modification, or to implement our own bootloader in SW.

13

I believe he was talking about the bootloader of the pico…

But anyways, I do think the STM32F1 can reach the bootloader from software… even though we may have to do something extreme like wiping a portion of the flash :laughing:

14

Oh! Maybe you right… I had a similar issue with the stm32 reflashing step, so I easily made the confusion!

I’ve used “bootloader<=>app” switch mechanisms on ARM architecture a lot in my professional work. I’m not sure to understand why this doesn’t properly work on memory of the F10xxx serie…
Maybe something related to the relative addressing who mess up with the linking of the ST bootloader.
Fortunatly (or not…) this memory part is a ROM, it can’t be overriden by misstake.

I’ll probably do some more testing later. The RTC registers need a release first!

15

I’m curious… do others get phantom key drops about 1 in 20 keystrokes if you’re not really careful? I’m wondering if this is a hardware issue or a firmware issue?

I’m wondering if it’s something that could be improved in the BIOS/keyboard firmware.

Thanks,

-Dave

16

I’d say hardware issue due to the switches they’ve used. You can get a mechanical click but nothing registered if pressing slightly off centre !

17

Yep, hardware lack of debounce elements… Can be handled from software side but not without some glitches.

I’m “typing” 2-3 key per second on the picocalc keyboard, I rarely miss a key or have a double one. (>1/100)

18

this is excellent!

i may be jumping the gun as i don’t have my PicoCalc yet, but as a C embedded software engineer by trade, is there a way we can contribute?

i’ve been kicking the ground procrastinating setting myself up a gitea :slight_smile:

2 Likes
19

I have normally left binaries ready to be flashed onto the Picocalc (and partially functional with PicoMite, MicroPython, etc.) for testing on multiple consoles and over long periods of time.
If you’re comfortable with embedded development, you can take a look at the code if you notice anything that seems “wrong” or simply for inspiration.

Hope you receive your picocalc soon!