Empty TX FIFO of PIO

[SteKme]

Hi,

please is there a way to empty TX (!!not RX!!) FIFO of the PIO before the PIO start? I kind of think that the FIFO content survives the state machine reset and such. What I need is to repeatedly restart the PIO that fetches data from RAM and on every restart, I need to start with the same sequence of bytes sent to PIO, however when the PIO is stopped, there may be some data in TX FIFO left orphaned and I need to flush those and fill with the correct sequence beginning data instead.

I found only one way to do so: statemachine.exec("pull()") - this fortunately seems to work for me - is there any other way, please? It is easy to poll the number of items in the FIFO, indeed, but I couldn't find any uPy command to empty it...

Thank You so much,
Stepan

[rkompass]

statemachine.exec("pull()")
was my method of choice and I had no problem with using it whenever needed.
Afaik or recall now there is no other method.

[SteKme]

@rkompass - Raul, please does this .exec() call alter the PIO program loaded in the statemachine's memory?

• I have the state machine programmed, the SM's memory is unfortunately completely full (all 32 instructions taken).
• I experience a lockup of the Pico on second run - on the first run, the TX fifo is empty, therefore statemachine.exec("pull()") isn't called as there is nothing orphaned in it, the statemachine is started and works just fine.
• on the second run, the fifo gets flushed with this exec("pull()") call, it seems, however sm.activate(1) causes the Pico to hang up altogether - bad is: sometimes, mostly. But not always (in theory, sometimes there may be nothing left in the fifo before the second run, I am usure).
• simply, I have the state machine set up, need to flush TX, activate SM, run and add items to TX when it becomes almost empty, finally deactivate SM. And repeat again and again.

This is confusing, I can't make any sense out of this... trying to narrow possible culprits somehow.

I am not sure how this exec() works, the instruction is directly propagated in the instruction decoding register (or whatnot), or the call modifies the statemachine's memory in some way? Don't You know by chance?

Thank You so much!

[SteKme]

more details -

• so the Pico didn't lock itself up. It got just busy in a trivial loop:
  while self.sm.tx_fifo()>0:
  self.sm.exec("pull()")

sm.exec("pull()") does flush the TX entry, but just one. For whatever reason, first call decreases TX data by 1 entry, but repeated calls do nothing here.

Further investigating...

[SteKme]

ok, I found a workaround, restarting the PIO multiple times just after actual start without refilling the TX fifo solves my problem hopefully (1st value I pass to the PIO is specific, but a full 32bit value and therefore each restart of the statemachine pulls additional 32 bits), but still it seems to me that the loop

while self.sm.tx_fifo()>0:
self.sm.exec("pull()")

just doesn't work as I anticipated, just one TX entry got flushed in my case...

[SteKme]

-- thank You, Raul, for confirming.
I think I can live with this, fortunately this instant exec doesn't require me to offload PIO code from the state machine.