Stopping/Clearing-out/Restarting PIO blocks -> microPython BUG

[mungewell]

I have a (quiet complex) project that is using all the PIO on a RP2040 - every engine, all locations, using FIFOs and IRQ for communications. The project has different operation at different times, so I'm attempting to clear/re-load the PIOs.... and I am seeing that the 2nd time running the same code, it doesn't work :-(

There must be something 'sticky' changing how the StateMachines work (or don't).

I have this 'take down' code:

    # Stop all StateMachines, disable IRQs and empty RX FIFOs
    for m in eng.sm:
        m.active(0)
        m.irq(handler=None)
        #print("TX FIFO", m.tx_fifo())
        #print("RX FIFO", m.rx_fifo())
        while m.rx_fifo():
            m.get()

    rp2.PIO(0).remove_program()
    rp2.PIO(1).remove_program()


    # 'Purge' statemachines to ensure TX FIFOs are empty
    irq_fifo_sm = []
    for i in range(8):
        irq_fifo_sm.append(rp2.StateMachine(i, irq_fifo_purge, freq=1_000_000))

    for m in irq_fifo_sm:
        m.active(1)
        sleep(0.1)
        m.active(0)
        #print("TX FIFO", m.tx_fifo())
        #print("RX FIFO", m.rx_fifo())

    rp2.PIO(0).remove_program()
    rp2.PIO(1).remove_program()

    '''
    # DEBUG: check the PIO code space/addresses
    for base in [0x50200000, 0x50300000]:
        for offset in [0x0d4, 0x0ec, 0x104, 0x11c]:
            print("0x%8.8x : 0x%2.2x" % (base + offset, mem32[base + offset]))
    print()
    '''

    eng.set_stopped(True)
    #print("Pico-Timecode Thread Stopped")

Any other suggestions on what I can try between PIO loadings?

[GitHubsSilverBullet]

If you take all the StateMachines down anyways, you might as well delete all eight StateMachines-instances and reinstate them fresh. Would be a clear cut.
If it still won't work, then the registers might be left in an undesirable state and need manual cleanup.

[mungewell]

Agree, and this is what my code does. It completely clears out the SMs and re-loads each of them.

I have discovered the issue... see below.

[mungewell]

After spending a few more hours (around 10hours spent on this) I think I have discovered a bug with microPython!

It's not easy seeing what happening within the PIO blocks, but you can read (mem32) the address pointer and the current command - which is the first command before the machine is made .active(1).

loading_wrong_code.txt

In this log I am alternately loading auto_start() and start_from_sync() state machines, which are the gatemen of the system. They are started last and use IRQ to synchronise the other machines. When auto_start() is loaded the second time (third cycle) the code that is pushed in to the PIO is actually the start_from_sync() code. BUG.

Mode Run 0
[StateMachine(0), StateMachine(1), StateMachine(2), StateMachine(3), StateMachine(4), StateMachine(5), StateMachine(6)]
0x502000d4 : 0x00000015 = 0x0000e021 <= X=1, this is 'auto start'

Mode Jam 64
[StateMachine(0), StateMachine(1), StateMachine(2), StateMachine(3), StateMachine(4), StateMachine(5), StateMachine(6)]
0x502000d4 : 0x00000015 = 0x0000e020 < X=0 means 'start from sync'

Mode Run 0
[StateMachine(0), StateMachine(1), StateMachine(2), StateMachine(3), StateMachine(4), StateMachine(5), StateMachine(6)]
0x502000d4 : 0x00000015 = 0x0000e020 <= WTF... this is the wrong code!!!

I was also able to re-create this BUG in a short example code.
pio_load_test.py.txt

MicroPython v1.26.1 on 2025-09-11; Raspberry Pi Pico with RP2040
Type "help()" for more information.

>>> %Run -c $EDITOR_CONTENT

MPY: soft reboot
Loading primary: mac-one
0x502000d4 : 0x0000001c = 0x0000e021
0x502000ec : 0x0000000b = 0x00006026
0x50200104 : 0x00000006 = 0x00007e01
0x5020011c : 0x00000001 = 0x0000ae08
RX FIFO = 1

Loading alternate: mac-two
0x502000d4 : 0x0000001c = 0x0000e022
0x502000ec : 0x0000000b = 0x00006026
0x50200104 : 0x00000006 = 0x00007e01
0x5020011c : 0x00000001 = 0x0000ae08
RX FIFO = 2

Loading primary: mac-one
0x502000d4 : 0x0000001c = 0x0000e022
0x502000ec : 0x0000000b = 0x00006026
0x50200104 : 0x00000006 = 0x00007e01
0x5020011c : 0x00000001 = 0x0000ae08
RX FIFO = 2

[GitHubsSilverBullet]

Have you checked how your »push(x)« is encoded? Because that's not a valid statement.

[mungewell]

OK... impossible to read the location in PIO address space.

>>> rp2.asm_pio_encode("push()", 0)
32800
>>> rp2.asm_pio_encode("push(x)", 0)
32768

If I change the example to just push(), the example fails in the same way. Re-loads the wrong code, ie with x=2.

Edit:
And just for the record here's how the set() is encoded. Which we can read prior to starting the PIO with .active(1)

>>> print("0x%8.8x" % rp2.asm_pio_encode("set(x,1)", 0))
0x0000e021
>>> print("0x%8.8x" % rp2.asm_pio_encode("set(x,2)", 0))
0x0000e022

[mungewell]

Wild guess, but "if it's not already there" sounds like something that could be misguided...

https://github.com/micropython/micropython/blob/master/ports/rp2/rp2_pio.c#L645

    // Get and the program offset, and load it into memory if it's not already there.
    mp_int_t offset = mp_obj_get_int(prog[PROG_OFFSET_PIO0 + pio_get_index(self->pio)]);
    if (offset < 0) {
        rp2_pio_add_program(&rp2_pio_obj[pio_get_index(self->pio)], args[ARG_prog].u_obj);
        offset = mp_obj_get_int(prog[PROG_OFFSET_PIO0 + pio_get_index(self->pio)]);
    }

[mungewell]

As a workaround it (test script) appears to correctly work if you implicitly specify the StateMachine to remove

    # clean-up
    rp2.PIO(0).remove_program(mac_one)
    rp2.PIO(0).remove_program(mac_two)
    rp2.PIO(0).remove_program()

Docs suggest this should not be necessary.
https://docs.micropython.org/en/latest/library/rp2.PIO.html#rp2.PIO.remove_program

Edit - confirmed workaround also works for my main project

[mungewell]

reported as a bug:

#18646