MicroPython experimental port for the Dabao (Baochip-1x RISC-V)

[mattytrentini]

Overview

The Dabao is an awesome RISC-V eval board built around the Baochip-1x SoC, both created by @bunnie. @andrewleech and I have been working on a port for MicroPython building on @ArmstrongSubero's daobao-sdk.

This port is still experimental, but if you have a Dabao, I'd love some testers!

[Also, anyone arriving here via DEFCON 34, I think your badge may also work. I'd be very keen to hear if it does/doesn't work!]

Details

Implemented features:

• machine.Pin (digital I/O, Pin.board aliases + full Pin.cpu PA0-PF15 access) and machine.Signal
• machine.I2C (hardware, fixed to I2C0_SCL/I2C0_SDA) and machine.SoftI2C (any pins)
• machine.SPI (hardware, fixed to the SPI2_* pins) and machine.SoftSPI (any pins)
• machine.RTC
• machine.WDT
• machine.PWM (8 channels: PB0-PB3 and PC0-PC3, two slices of 4 sharing a frequency each)
• os.urandom() (hardware TRNG)
• machine.bootloader()
• Native USB-CDC — the REPL is available over USB-CDC and the UART2 REPL simultaneously

Not yet implemented: machine.UART, machine.ADC, filesystem/storage...

Flashing the prebuilt firmware

Unzip and deploy firmware.zip

1. Put the board in boot1: hold PROG, tap RESET, hold PROG ~1s, release.
2. A USB mass-storage drive appears, drag firmware.uf2 onto it.
3. The board reboots into the new firmware automatically.

Building it yourself

Install a recent version of mpbuild.

git clone -b baochip-i2c-spi https://github.com/mattytrentini/micropython
mpbuild build DABAO

You'll find the UF2 in ports/baochip/build-DABAO/firmware.UF2.

Any feedback would be very welcome!

[andypiper]

Ah! i was wondering how long this might take!

I have a board waiting for me in the studio and I'll give this a test soon!

[dpks2003]

I received mine today. I willl give it a try

[burtyb]

[gear, no idea] I'm probably missing something but after copying firmware.uf2 it didn't reboot here, I tried typing "boot" over the USB serial and I could then see "MicroPython v1.29.0-preview.457.ga7b7409173 on 2026-08-05; DABAO with Baochip-1x" on the new USB serial port after it restarted and from there I was able to see life toggling SPI2_CS.

[andrewleech]

Yeah the builtin bootloader is a little different to some other UF2 bootloaders - after copying the binary on I think you can press one of the pushbuttons to load it too - as opposed to eg a rp2 which auto-reboots after copying the uf2 file on!

[mattytrentini]

machine.ADC support is added with firmware.ffde4ee5b.zip

Just for clarity, development is on this fork/branch: https://github.com/mattytrentini/micropython/tree/baochip-i2c-spi

[ewenmcneill]

Regarding these programming instructions:

Put the board in boot1: hold PROG, tap RESET, hold PROG ~1s, release.
A USB mass-storage drive appears, drag firmware.uf2 onto it.
The board reboots into the new firmware automatically.

it looks like those are written for either a board other than the Dabao, or at least a non-standard bootloader setup.

Factory configuration is that the Dabao has bootwait enable set, which causes it to wait in the boot loader on power up (ie, with the USB Mass Storage available). This also happens when RESET is pressed by itself. (The PROG-hold, RESET, PROG-hold 1 more second then release dance will also work whether or not bootwait is enabled, but it's unnecessary in the factory bootloder config.)

You can exit that bootloader either by pressing the PROG button by itself, or (I think) by running boot on the (USB ACM) serial console. The only obvious signs that worked are (a) the USB Mass Storage goes away, and (b) (with MIcroPython) the USB PID changes to f055:9802 (rather than the Baochip ones), since there's no LEDs or similar on the Dabao itself. (Running boot on the USB ACM serial console has the disadvantage that as soon as you do so the USB ACM device will disappear :-) )

NOTE: you should sync or umount the BAOCHIP file system before you press the PROG button to make sure it got fully flushed to the device, otherwise the firmware update may be incomplete or not work. (In which case just try again, as the bootloader isn't touched by this application update process.)

Also for anyone just finding this discussion as their first point of contact, (USB ACM) serial console is at 1Mbps (1000000), both in the bootloader and the MiicroPython (but note they're different USB VID:PID values, so the USB ACM serial console device goes away and gets recreated).

With those tweaks to putting code on the Dabao, I did get the first build running on my board:

>>> import sys
>>> print(sys.version)
3.4.0; MicroPython v1.29.0-preview.457.ga7b7409173 on 2026-08-05
>>> 

Also for completeness the build from about an hour ago (message above mine) also works for me:

>>> import sys
>>> print(sys.version)
3.4.0; MicroPython v1.29.0-preview.458.gffde4ee5b8 on 2026-08-06
>>> 

Ewen

[stevens101]

I tried the machine.RTC on a Dabao, but the clock was running quite fast. I'm not sure how to correct that.

[bunnie]

I am not familiar with how the RTC is implemented in this but I will say that I do clock the RTC hardware at 1/1024 second per tick and not 1 second per tick, so if the driver assumes 1s/tick then things will indeed run very fast.

[ewenmcneill]

Looks like the Micropython RTC is reading the RTC counter via the C SDK, and seems to be assuming it is in seconds.

https://github.com/mattytrentini/micropython/blob/ffde4ee5b88fa70ba3853a85993a8ca36bb6eb4a/ports/baochip/machine_rtc.c#L40-L43

but the rtc_init() / rtc_start() (from the C SDK) being called look like they don't set the RTC divider:

https://github.com/ArmstrongSubero/dabao-sdk/blob/bcc3eb77b1aa56d57918434a1abcc5f35940f1dd/src/bao1x/hardware_rtc/rtc.c#L48-L69

so I think that means the RTC divider is "whatever the bootloader set", and definitely faster than real time.

Eg, test example, with the last command run maybe 10 seconds after the second command:

>>> rtc = machine.RTC()
>>> rtc.datetime((2026,8,7,20,32,35,0,0))
>>> rtc.datetime()
(2026, 8, 8, 5, 9, 38, 9, 0)
>>> 

(values are YYYY, MM, DD, HH, MM, SS, MS, TZ-offset)

So my guess is that setting the clock divider via the C API to some plausible value would make it tick at least at "near real time".

ETA: this being the function to set the RTC divider in the C API:

https://github.com/ArmstrongSubero/dabao-sdk/blob/bcc3eb77b1aa56d57918434a1abcc5f35940f1dd/src/bao1x/hardware_rtc/rtc.c#L38-L45

(there's a 9u constant above that, but as best I can tell it's never used.)

Ewen

[ArmstrongSubero]

Good spot! The 9u constant is left over from when I baked in the calibration routine for testing, I removed it to add flexibility to the SDK for people who are using Baochip with other boards and wanted C support, but now I'm reasoning the Dabao case is probably broad enough to leave it in there and can integrate without breaking the existing API... worth noting there isn't a plausible fixed value for the Dabao, because the source is an RC oscillator that varies per chip, that's why it has to be a measurement rather than a constant, next sweep I'll make sure an update that, maybe over this weekend or mid next week I'll make sure its cleaned up...

[ArmstrongSubero]

The RTC divider is the issue. rtc_init() deliberately leaves it at whatever the boot chain set, which is 15, giving about 749 Hz. Call rtc_set_divider() before using it.

The complication is that the source is an internal RC oscillator, not a crystal, so there's no fixed correct value. Measured on my board it runs around 11,980 Hz after the fixed /32, and it varies per chip and drifts about 0.25% as the board warms, which is roughly 200 seconds a day. So it needs calibrating against something stable rather than hardcoding a divider....

The relationship is rate = F_raw / (divider + 1), confirmed at five divider values. One special case is that divider 0 gives about 0.70x what the formula predicts, so don't calibrate from it.....

For MicroPython, machine.RTC wants seconds, so either divide down to 1 Hz with a calibration pass at init, or take bunnie's 1024 Hz and shift right by 10....

Unrelated but worth knowing since it's easy to conflate, the "32K" reference the ATimer uses is a different clock. That one is 48 kHz, derived from the 48 MHz crystal, and it measured exactly 48,000 on five consecutive runs with no variation... if you need a stable slow clock, that's the one...

So for the SDK, Calibration is a single measurement and the RTC tick rate follows a plain relationship:

rate = F_raw / (CLK1HZ_FD + 1)

So if you set a known divider, measure the resulting tick rate, and multiply back, you recover F_raw. Then the divider for 1 Hz is simply F_raw minus one.

You can use this for calibration:

/* Probe at a known-good divider, work out F_raw, then set the
 * divider that yields 1 Hz. Takes about two seconds.
 *
 * Do NOT probe at divider 0. It is a special case that reports
 * roughly 0.70x the rate the formula predicts, and calibrating
 * from it produces a divider that is badly wrong. */
#define RTC_PROBE_DIV   9u
#define RTC_FD_MASK     0x3FFFu   /* 14-bit field */

void rtc_calibrate(void) {
    rtc_stop();
    AON_CLK1HZ_FD = RTC_PROBE_DIV;
    rtc_set_time(0);
    rtc_start();

    delay_ms(50);                    /* let it settle */

    uint32_t r0 = rtc_get_time();
    uint64_t t0 = millis();
    delay_ms(2000);
    uint32_t r1 = rtc_get_time();
    uint32_t dt = (uint32_t)(millis() - t0);

    /* ticks per second at the probe divider */
    uint32_t rate = (uint32_t)
        (((uint64_t)(r1 - r0) * 1000u) / dt);

    /* rate = F_raw / (probe + 1)  ->  F_raw = rate * (probe + 1) */
    uint32_t f_raw = rate * (RTC_PROBE_DIV + 1u);

    /* 1 Hz needs divider = F_raw - 1 */
    uint32_t div = f_raw - 1u;
    if (div > RTC_FD_MASK) div = RTC_FD_MASK;

    rtc_stop();
    AON_CLK1HZ_FD = div;
    rtc_set_time(0);
    rtc_start();
}

[ewenmcneill]

Thanks for the detailed explanation, and example code.

I think it'd be worth including your rtc_calibrate() function into the C SDK, as something that callers could choose to use (instead of rtc_start() -- maybe calling it rtc_calibrate_and_start() or similar). I do agree with your comments elsewhere that given the differences in board support (some boards have only RC-oscillator, some have a tuned crystal) it should probably be up to the caller to decide to set the divider directly or use the automated calibration attempt.

Also I'd suggest considering omitting the rtc_set_time(0) from that calibration function, and leave that for the caller to set separately.

Ewen

[ArmstrongSubero]

Worth adding that the RTC block itself is an ARM PrimeCell PL031, and PL031 is a 1 Hz seconds counter by design... DR reads seconds and LR sets seconds, and that's the whole contract. So the MicroPython driver reading DR as seconds is correct behaviour, the problem is entirely upstream, PL031 is being fed roughly 749 Hz instead of 1 Hz, and it's faithfully counting what it's given... the fix belongs in whatever configures CLK1HZ_FD before the RTC is used... I'll add the calibration to rtc_init() in the C SDK so callers don't have to deal with this at all....

[bunnie]

Ah right, Dabaos don't have a crystal - so you're correct the RTC is basically not really actually an RTC. This path makes a lot more sense on baosec/baosec-lite targets which have the external 32kHz crystal.

[ArmstrongSubero]

Yes, thats why I'd deliberately left the divider alone rather than baking in a calibration pass, since the right value depends on the board and I didn't want rtc_init() making that decision for people... cause some may have Dabao, maybe some Baosec or something custom, so idea is pull default and only divide if you need to and run custom calibration if you don't have a crystal hooked up... but since its going into MicroPython, and I'm about to start getting around to a CircuitPython port, the Dabao case is common enough, and the failure is silent enough, that it's probably the wrong default.... anyone who wants RTC with Dabao though 200 secs a day drift isn't really time keeper territory, so if you wanna use it across days people are going to need an external chip.... or use the workaround with another timer module driven by the crystal and do their own RTC routines using that as a timebase..... I'm keeping all these as notes to update The Dabao Book, the few ppl who got a copy already gave me feedback on some things they would like added in... and this is the second time accurate RTC on Dabao came up so interfacing an external RTC and workarounds for accurate time and what not is def something I'm putting out in the update...

[stevens101]

Thanks, I added your rtc_calibrate() and now the RTC is working better. Sorry, I wasn't expecting real time without the hardware for it, but this good enough!

[MichaelBell]

This is great to see - I just got my hands on a dabao dev board and got this up and running with a bit of help from ewenmcneill's comment - thanks!

It would be great to put a LittleFS filesystem in ReRAM - maybe use the top 2MB? Without one Thonny can't connect as it assumes there will be some kind of filesystem present.

[mattytrentini]

Thanks for the feedback! :) LittleFS support has been started but it's non-trivial with the somewhat unusual RRAM. I'll keep chipping away at it.

[dldatwyler]

Something new to learn. As always.

Thank you for doing this work.