PIO code behaving very differently between simulator & real Pico (Wokwi 👍 , Pico 🤯 )

[rtyley]

I wrote some PIO code to drive a pair of Holtek HT1632C chips (1 data, 1 write clock, 2 chip-select lines) - the code is behaving perfectly in Wokwi simulator, and is behaving completely differently when run on an actual RPi Pico. I tried a Pico 1 & 2, and a Pico W too... all were consistent with each other, just not making any output that I recognised as making sense.

The micropython code pushes data (number of bits to write for each Chip Select, and then the bits themselves) onto the state machine’s TX FIFO. The PIO code (included at the bottom) outputs the Data signal to GPIO Pin 10, and uses sideset to output the Write Clock, CS0 & CS1 to Pins 11,12,13 (ie Write Clock on Pin 11 is the sideset base).

In this demo example, the code runs on repeat, the same data being pushed into the TX FIFO every 1 second.

Wokwi 👍

https://wokwi.com/projects/426164473278649345 ...gives this signal, output every 1 second:

This is completely perfect to my eyes - the Write clock oscillates along, giving 22 rising edges while Chip Select 0 is low, and then does another 22 rising edges while Chip Select 1 is low. The correct data is written out to the data line (eg 101 0000000 1111 1000 0001 while CS0 is low).

Real Pico 🤯

Sticking the same code into Thonny, deploying it to a real live Pico (Micropython v.24.1), and capturing the resulting signals with a logic analyzer, gives a completely different set of signals (still output once every second):

Differences:

• CS0 is always low (should only be low for the first half of the signal)
• CS1 is always high (should be low for the second half of the signal)
• Write Clock is giving 128 rising edges... not 44.
• Data is completely blooming different - for instance, starting with 3 pulses, not 2.

This signal isn't pure random noise - all 4 of these signals always look exactly the same, repetition after repetition, run after run.

What is going on?!

I don't know what I'm doing wrong!

So far as I can tell, on the physical Pico, I am monitoring the correct GPIO pins:

If I add Micropython code to set the Chip Select lines high (pin_cs0.on()) then I can see that happening in my logic analyzer - but the PIO sideset still seems to do nothing for the CS lines.

Code

import rp2
from rp2 import PIO
from machine import Pin
from time import sleep

@rp2.asm_pio(set_init=[PIO.OUT_LOW] * 1, out_init=[PIO.OUT_LOW] * 1, sideset_init=[PIO.OUT_HIGH] * 3, autopull=True,
             fifo_join=PIO.JOIN_TX)
def dualHoltekHT1632C():
    wrap_target()
    label("init")
    pull(block).side(0b111)
    mov(x, osr)
    pull(block)
    mov(y, osr)

    pull(block)
    jmp(not_x, "cs1_start")
    nop().side(0b101)  # 'tsu1' setup time for CS to WR clock width (300ns BEGINS)
    nop().delay(1)
    label("cs0_loop")
    out(pins, 1).side(0b100)  # 'tsu' setup time for Data to WR clock width (100ns BEGINS)
    nop().side(0b101)  # 'th' hold time for Data to WR clock width (200ns BEGINS)
    jmp(x_dec, "cs0_loop")
    set(pins, 0)

    label("cs1_start")
    jmp(not_y, "init").side(0b111)
    nop().side(0b011)
    nop().delay(1)
    label("cs1_loop")
    out(pins, 1).side(0b010)
    nop().side(0b011)
    jmp(y_dec, "cs1_loop")
    set(pins, 0)
    wrap()


sm = rp2.StateMachine(0, dualHoltekHT1632C, freq=3000000, set_base=Pin(10), out_base=Pin(10), sideset_base=Pin(11))

sm.active(1)

while True:
    sm.put(22 - 1);
    sm.put(22 - 1);
    sm.put(0xA03E0681);
    sm.put(0xF1800000);

    # 10100000001111100000011010000001111100011000

    sleep(1)

[mendenm]

Just as an experiment, have you tried switching from optional side set mode to full side set mode, in which each instruction has a side set on it? I don’t quite see how that would make a difference, but it does change the code and a bit in the configuration register, along with leaving an extra bit for delays.

[Josverl]

not a solution , but a PIO emulator that I have found quite useful for testing and debugging my PIO code.

https://github.com/NathanY3G/rp2040-pio-emulator

[mendenm]

@rtyley Try disabling auto pull. You are both pulling and auto pulling, so your mov(x,osr) triggers another pull immediately, and the you pull yet again before the mov(y, osr)

[rtyley]

@mendenm I'm fairly sure that I do want auto-pulling - without autopulling I would need another counter to know when to pull again during these lines that are outputting to the Data pin:

    jmp(not_x, "cs1_start")
    nop()                  .side(0b101) # 'tsu1' setup time for CS to WR clock width (300ns BEGINS)
    nop().delay(1)
    label("cs0_loop")
    out(pins, 1)           .side(0b100)     # 'tsu' setup time for Data to WR clock width (100ns BEGINS)
    nop()                  .side(0b101) # 'th' hold time for Data to WR clock width (200ns BEGINS)
    jmp(x_dec, "cs0_loop")
    set(pins, 0)

    label("cs1_start")
    jmp(not_y, "init")     .side(0b111)
    nop()                  .side(0b011)
    nop().delay(1)
    label("cs1_loop")
    out(pins, 1)           .side(0b010)
    nop()                  .side(0b011)
    jmp(y_dec, "cs1_loop")

...perhaps I shouldn't be manually pulling after MOV during the initial lines? :

    label("init")
    pull(block)            .side(0b111)
    mov(x, osr)
    pull(block)
    mov(y, osr)
    
    pull(block)

It wasn't clear to me what conditions increment the autopull shift-count, but having a look at the RP2040 datasheet in section '3.5.4. Autopush and Autopull', it says:

State machines keep track of the total shift count OUT of the OSR and IN to the ISR, and trigger certain actions once these counters reach a programmable threshold.
• On an OUT instruction which reaches or exceeds the pull threshold, the state machine can simultaneously refill the OSR from the TX FIFO, if data is available.

...so it mentions OUT instructions, which are shifting data from OSR to the out-pins, but doesn't mention mov x, osr, which is copying the whole of the OSR into X. Elsewhere, in the documentation for MOV it does say, when OSR is the destination:

Output shift counter is reset to 0 by this operation, i.e. full

...but that's when OSR is the destination, not source.

This is repeated by section '3.2.3.3. Shift Counters':

On PIO reset, or the assertion of CTRL_SM_RESTART, the input shift counter is cleared to 0 (nothing yet shifted in), and the
output shift counter is initialised to 32 (nothing remaining to be shifted out; fully exhausted). Some other instructions
affect the shift counters:
• A successful PULL clears the output shift counter to 0
• A successful PUSH clears the input shift counter to 0
• MOV OSR, … (i.e. any MOV instruction that writes OSR) clears the output shift counter to 0
• MOV ISR, … (i.e. any MOV instruction that writes ISR) clears the input shift counter to 0
• OUT ISR, count sets the input shift counter to count

So in your remark:

your mov(x,osr) triggers another pull immediately

...I think that mov(x,osr) does not change the shift count, and so does not trigger another pull?! Or maybe it does, and it's just not documented?

However, I did try removing the pull(block) instructions after mov(x, osr) & mov(y, osr) to see if it helped correct the Pico output:

    label("init")
    pull(block)            .side(0b111)
    mov(x, osr)
    # pull(block)
    mov(y, osr)
    
    # pull(block)

...and unfortunately the output was still incorrect 😞

[mendenm]

You’re right that the documentation isn’t very clear about the effect of mov instructions on autopull. I’ll write a quick test to see if they trigger it or not. I can’t see anything else wrong or suspicious about your code.

[mendenm]

@rtyley
OK, I did some diagnostics by adding:

    mov(isr, x)
    push()
    mov(isr, y)
    push()

to the sm code, and monitoring the rx_fifo (I disabled the fifo join). If definitely shows a problem with the autopull, since the wrong numbers are turning up in the count registers. I note that you never set an autopull threshold, since your number of bits vary. This means the threshold was its default value of 32, so the system is kind of randomly pulling bits, since you are shifting out 22 at a time. For your particular test case, if I turn off autopull, and add an extra pull in the second code block, it seems to work exactly right.

Incidentally, you are right that mov(y, osr) doesn't pull. I explicitly depend on this behavior in by bus analyzer (which is what I am using to debug the output of your code) at:
https://github.com/mendenm/rp2_micropython_tricks/blob/main/data_compressing_analyzer.py

In this case, I am using the osr as a cache to get an extra register.

I think autopull might not be usable in your case, unless the length of the bit stream is always the same.

The behavior of pull() when autopull is enabled is a bit mysterious to me. I have fiddled with your code with autopull on, and inserted extra pull()s, and don't quite know what I am seeing.

[pmturlais]

When using autopull, it is better to replace pull(noblock)/mov(?,osr) with out(?,32). It seems that in autopull mode, pull just copy osr to destination. You also have to flush the osr to realign the words. The following code does both.

@rp2.asm_pio(set_init=[PIO.OUT_LOW]*1, out_init=[PIO.OUT_LOW]*1, sideset_init=[PIO.OUT_HIGH]*3, autopull=True, fifo_join=PIO.JOIN_TX)
def dualHoltekHT1632C():
    wrap_target()
    label("init")
    ### Replace pull/mov with out(?,32)
    out(x, 32)               .side(0b111)
    # pull(block)            .side(0b111)
    # mov(x, osr)
    out(y, 32)
    # pull(block)
    # mov(y, osr)

    ### This pull is not needed, the next out will do it
    # pull(block)
    jmp(not_x, "cs1_start")
    nop()                  .side(0b101) # 'tsu1' setup time for CS to WR clock width (300ns BEGINS)
    nop().delay(1)
    label("cs0_loop")
    out(pins, 1)           .side(0b100)     # 'tsu' setup time for Data to WR clock width (100ns BEGINS)
    nop()                  .side(0b101) # 'th' hold time for Data to WR clock width (200ns BEGINS)
    jmp(x_dec, "cs0_loop")
    set(pins, 0)

    label("cs1_start")
    jmp(not_y, "init")     .side(0b111)
    nop()                  .side(0b011)
    nop().delay(1)
    label("cs1_loop")
    out(pins, 1)           .side(0b010)
    nop()                  .side(0b011)
    jmp(y_dec, "cs1_loop")
    set(pins, 0)

    ### There is some bits left over in OSR, flush them
    # Not sure of the hanling of number of bits shifted multiple of 32 ????
    jmp(not_osre, "clear_osr")
    jmp("init")
    label("clear_osr")
    out(null, 32)
    
    wrap()

[Josverl]

Has this difference in runtime behavior been reported to Wokwi yet?
@urish may have a view on this from the emulator side as well.

[rtyley]

I haven't yet- I was wondering if there was some arbitrary state (maybe the output shift counter) that could take some undefined value so that perhaps what Wokwi was doing was not technically wrong. If Wokwi is doing something wrong, it would be nice to isolate a smaller reproduction of the issue to more clearly report it, but I haven't had the time over the past few days!

[Josverl]

Lets first disect to a minimal reproduction, and possible difference in runtime behavior.
After that we can understand better what the cause is, it may be just a difference in initial state

[rtyley]

@rtyley What is the real nature of the data to be sent to this device? Is it always short streams, as in the example, or are these really long, packed string of bits in real life, for which autopull is the elegant solution?

Thanks @mendenm, the data is sent to a pair of Holtek [HT1632C](https://cdn-shop.adafruit.com/datasheets/ht1632cv120.pdf) chips, and has a format like this: <img width="704" alt="image" src="https://github.com/user-attachments/assets/90d890c2-c621-41d6-8d26-8bcd77ba2f2a" /> ``` ccc aaaaaaa dddd dddd dddd dddd dddd ... ccc : 3 bit mode selector, 101 for 'write mode' aaaaaaa : 7-bit memory address dddd : a 4-bit nibble giving the lighting state for 4 leds - this can be repeated up to 96 times to cover all 96*4 LEDs the HT1632C can control ``` So the data length for sending to a single bulk-write command HT1632C can be anywhere from 14 bits, up to 394 bits, in 4-bit increments. That's for just one HT1632C chip, the PIO code is meant to drive a dual-HT1632C device, so there may be up to **788 bits** for the both of them.