Sync PIO to 1us Counter Tick = "Nudge-lock"... plus RP2350 DMA question.

[mungewell]

More of my precise timing quest, seems this is getting quite in-depth.

I'd like to sync my PIOs (running at full CPU speed) to the 1us counter tick. It does not seem that this is an easy task, but digging through the (RP2040) datasheet I might have a scheme. Please tell me if there is an easier way...

It looks like the 1us Tick is created by the Watchdog module, from the REF_CLOCK which runs at 12MHz. Watchdog divides down by 12 and sends this Tick back to the Timer/Counter module. Unfortunately this is not exposed in a way to route/access from the PIOs.

So, my scheme:

• configure CLOCK_GPOUT0 to follow REF_CLOCK and enable on GPIO21
• configure to same 'divide by 12' as 1us Tick
• PIO trigger DMA transfer every 'x' rising edges of GPIO21
• DMA reads 'Watchdog Countdown', which contains how many clocks left until the next Tick, and pushes to FIFO 'reflector'
• script monitors this FIFO/value, and if it is not maximum ('12') it 'nudges' CLOCK_GPOUT0 which should change it's phasing slightly.

If the FIFO constantly reads back '12' this confirms that the CLOCK_GPOUT0 rising edge is aligned to the 1us Tick.

Issues:

• The datasheet suggests that 'nudge' changes phase by 1 clock cycle, but it appears to change by 2. So if the alignment is 'odd' at start the process can never complete.
• my DMA scheme doesn't complete/function on RP2350, suggestions?

Script:
nudge.py.txt

Good run

MPY: soft reboot
Running on RP2040
Setting up StateMachines
Setting up DMA
Ready to nudge-lock to 1us Tick
Watchdog/Tick-Gen Countdown 0x008
Watchdog/Tick-Gen Countdown 0x008
Nudge CLOCK_GPOUT0
Watchdog/Tick-Gen Countdown 0x006
Watchdog/Tick-Gen Countdown 0x006
Nudge CLOCK_GPOUT0
Watchdog/Tick-Gen Countdown 0x004
Watchdog/Tick-Gen Countdown 0x004
Nudge CLOCK_GPOUT0
Watchdog/Tick-Gen Countdown 0x002
Watchdog/Tick-Gen Countdown 0x002
Nudge CLOCK_GPOUT0
Watchdog/Tick-Gen Countdown 0x00c
Watchdog/Tick-Gen Countdown 0x00c
Success

Bad run

MPY: soft reboot
Running on RP2040
Setting up StateMachines
Setting up DMA
Ready to nudge-lock to 1us Tick
Watchdog/Tick-Gen Countdown 0x009
Watchdog/Tick-Gen Countdown 0x009
Nudge CLOCK_GPOUT0
Watchdog/Tick-Gen Countdown 0x007
Watchdog/Tick-Gen Countdown 0x007
Nudge CLOCK_GPOUT0
Watchdog/Tick-Gen Countdown 0x005
Watchdog/Tick-Gen Countdown 0x005
Nudge CLOCK_GPOUT0
Watchdog/Tick-Gen Countdown 0x003
Watchdog/Tick-Gen Countdown 0x003
Nudge CLOCK_GPOUT0
Watchdog/Tick-Gen Countdown 0x001
Watchdog/Tick-Gen Countdown 0x001
Nudge CLOCK_GPOUT0
Watchdog/Tick-Gen Countdown 0x00b
Watchdog/Tick-Gen Countdown 0x00b
...
Nudge CLOCK_GPOUT0
Watchdog/Tick-Gen Countdown 0x001
Watchdog/Tick-Gen Countdown 0x001
Nudge CLOCK_GPOUT0
Watchdog/Tick-Gen Countdown 0x00b
Watchdog/Tick-Gen Countdown 0x00b
Nudge CLOCK_GPOUT0
Watchdog/Tick-Gen Countdown 0x009
Watchdog/Tick-Gen Countdown 0x009
Nudge CLOCK_GPOUT0
Watchdog/Tick-Gen Countdown 0x007
Watchdog/Tick-Gen Countdown 0x007
FAIL

[GitHubsSilverBullet]

I'd like to sync my PIOs (running at full CPU speed) to the 1us counter tick. It does not seem that this is an easy task, but digging through the (RP2040) datasheet I might have a scheme. Please tell me if there is an easier way...

There's an easier way! ;-)

But not using the sluggish standard Python. Every call (mem32,…) takes ages. Instead write an tiny Viper function or even better an asm_thumb function. Stop the StateMachines, wait (in Assembler) for an increase of the systick and start the SMs. Done.

[GitHubsSilverBullet]

Even in assembler, any 'wait for'... will mean that the bus has already left the station.

Sure. But we're talking StateMachine Code. It is quite simple to initialize'em in a way that is shortened one or a few cycles for the first loop. And all of a sudden we're in perfect sync.

[mungewell]

OK, I didn't quiet understand what you were suggesting.... so you are saying?:

• set up StateMachine, but don't start it.
• freeze CPU in tight loop monitoring the 1us Counter, assume you mean "TIMERBASE + 0x28" = Address of TIMERAWL Register.
• write directly to SM registers to "active(1)" the StateMachine.

Can you give example code, I'm interested in how tight (and deterministic) that would be.

A little more background on what I am attempting:
riblettmj/TimePico#10

And with some more coding on the nudge.py script I have it syncing and then time stamping the CLOCK_GPOUT0 edge with a PIO counter running at "1 count per 2 cycles" and a CPU frequency of 256MHz. This results in the lower 7bits of the 32bit count being sub-us (ie 1/128th of a us) and the 8th bit being 1us. Each count value represents 7.8125ns.

Here the PIO is time stamping every rising edge, but I'm only reading the FIFO every ~100ms so as to not flood display

CLOCK_GPOUT0 timestamped at 0xa8610980 1 0x00
CLOCK_GPOUT0 timestamped at 0xa925ab00 1 0x00
CLOCK_GPOUT0 timestamped at 0xa9e8a800 0 0x00
CLOCK_GPOUT0 timestamped at 0xaaacf180 1 0x00
CLOCK_GPOUT0 timestamped at 0xab719080 0 0x00
CLOCK_GPOUT0 timestamped at 0xac348580 1 0x00
CLOCK_GPOUT0 timestamped at 0xacf8d680 0 0x00
CLOCK_GPOUT0 timestamped at 0xadbd7380 1 0x00
CLOCK_GPOUT0 timestamped at 0xae806d80 1 0x00
CLOCK_GPOUT0 timestamped at 0xaf44c100 1 0x00

You can see that the lower bits are all zero (ie perfectly synchronized) and the 8th is just indicating that this sample was either odd/even value of us. I have a plan for that bit to help me with another issue...

EDIT:
I picked the wrong single bit, >> 8 not the >>7 it should have been....

EDIT2:
And being a Electronics guy, having GPIO21 toggling gives me a place to attach a scope and visualize the 1us counter in relation to other scope'd signals.

[mungewell]

Another few hours coding and the scheme is really coming together... my Pico's XTAL is off by such a frequency that it thinks my 1PPS signal from GPS is actually an average period of 999995.559976247us (not unexpected)

Pin timestamped by 1us at 0x3396bbf9
Pin timestamped by PIO at 0x45047f4e 0 0x4e
Timestamp: 865516537.609375

Pin timestamped by 1us at 0x33a5fe35
Pin timestamped by PIO at 0x4ca59d17 0 0x17
Timestamp: 866516533.1796875

Pin timestamped by 1us at 0x33b54070
Pin timestamped by PIO at 0x5446bae4 1 0x64
Timestamp: 867516528.78125

Pin timestamped by 1us at 0x33c482ac
Pin timestamped by PIO at 0x5be7d8b0 1 0x30
Timestamp: 868516524.375

Pin timestamped by 1us at 0x33d3c4e8
Pin timestamped by PIO at 0x6388f67d 0 0x7d
validation failed, DMA late?
Timestamp: 869516519.9765625

Pin timestamped by 1us at 0x33e30723
Pin timestamped by PIO at 0x6b2a144a 0 0x4a
Timestamp: 870516515.578125

Pin timestamped by 1us at 0x33f2495f
Pin timestamped by PIO at 0x72cb3212 0 0x12
Timestamp: 871516511.140625

Note: the timestamps don't really have 6 decimal place (pico-seconds!!!), there are (7bit) fractions of us and it just makes them easier to visualize as decimals.

[GitHubsSilverBullet]

Pico's XTAL is off by such a frequency that it thinks my 1PPS signal from GPS is actually an average period of 999995.559976247us

That's a +4.45ppm deviation, a pretty good value.

[mungewell]

The main issue with the stock XTAL is the stability, mostly temp stability. You can put your finger on it and watch the value go up...

For my other project (which is more of a 'free-run' situation) stability is critical, and I have been replacing the XTAL with TCXO (temperature compensated XTAL oscillator)... since I have a few of these I just ran one for a bit.

average	1000000.62561888
min	1000000.5234375
max	1000000.703125

Obviously I can't control the jitter on the 1PPS signal, but this is with a Mosaic-X5 which should be pretty good.

Note: the banding shown is (I think) the 7.8125ns sampling rate/limit.

[mungewell]

An evening of bashing my head against the keyboard... what joy!

I have a small script which points to a DMA issue with RP2350, it appears that it's triggering a read error. But I don't know why!

import rp2
from os import uname
from time import sleep
from machine import mem32

a = bytearray(4)
b = bytearray(4)
d = rp2.DMA()

c = d.pack_ctrl()
#c = d.pack_ctrl(read_err=True)

# attempt to read the Watchdog/Tickgen countdown.
if 'RP2040' in uname().machine:
    print(mem32[0x4005802C])
    d.config(read=0x4005802C, write=b, count=1, ctrl=c, trigger=True)
else:
    # works....
    print(mem32[0x40108020])

    # Just returns zero, and when re-run doesn't complete... read error!!
    d.config(read=0x40108020, write=b, count=1, ctrl=c, trigger=True)
    #d.config(read=0x40108038, write=b, count=1, ctrl=c, trigger=True)

count = 5
while d.active() and count:
  count -= 1
  sleep(1)

if count:
    print("DMA transfer complete")
else:
    print("DMA transfer is still active:", d.active())
print(b)
d.close()

[mungewell]

Maybe the region protection???

from machine import mem32
from array import array

DMA_BASE = 0x50000000

# dump MPU_BAR0, etc...
c = 0
for i in [0x504, 0x50C, 0x514, 0x51C, 0x524, 0x52C, 0x534, 0x53C]:
    print("MBAR", c)
    c += 1
    print("Addr ", hex(mem32[i] & 0xffffffff))
    data = mem32[i+4]
    print("Limit", hex(data & 0xFFFFFFE0))
    print("S    ", hex((data & 0x4)>>2))
    print("P    ", hex((data & 0x2)>>1))
    print("En   ", hex(data & 0x1))
    print()

gives an active region which matches...

MBAR 6
Addr  0x3111c90c
Limit 0x43087800
s     0x0
P     0x0
En    0x1

[mungewell]

[mungewell]

To be clear, this is the register I am attempting to read... so I can "nudge-lock" to it.

[mungewell]

This might be working now....

import rp2
from os import uname
from time import sleep
from machine import mem32
import uctypes

DMA_BASE = 0x50000000
SECCFG_CH0 = DMA_BASE + 0x480

a = bytearray(4)
b = bytearray(4)
d = rp2.DMA()

ch_num = (uctypes.addressof(d.registers[0:1]) - DMA_BASE) // 0x40
mem32[SECCFG_CH0 + (ch_num * 4)] = 0x3

ACCESSCTRL_BASE = 0x40060000
ACCESSCTRL_PASSWORD = 0xACCE0000 #????

#PERIPH_OFFSET = 0x58 # CORESIGHT_TRACE
#PERIPH_OFFSET = 0xC0 # CLOCKS
PERIPH_OFFSET = 0xD4 # TICKS
#PERIPH_OFFSET = 0xD8 # WATCHDOG

mem32[ACCESSCTRL_BASE + PERIPH_OFFSET] = mem32[ACCESSCTRL_BASE + PERIPH_OFFSET] \
                                         | ACCESSCTRL_PASSWORD | 0x40 | 0x08

#c = d.pack_ctrl()
c = d.pack_ctrl(read_err=True)

# attempt to read the Watchdog/Tickgen countdown.
if 'RP2040' in uname().machine:
    print(mem32[0x4005802C])
    d.config(read=0x4005802C, write=b, count=1, ctrl=c, trigger=True)
else:
    # works....
    print("0x%3.3x" % mem32[0x40108020])
    #print(mem32[0x40108038])

    # Just returns zero, and when re-run doesn't complete... read error!!
    d.config(read=0x40108020, write=b, count=1, ctrl=c, trigger=True)
    #d.config(read=0x40108038, write=b, count=1, ctrl=c, trigger=True)

count = 5
while d.active() and count:
  count -= 1
  sleep(1)

if count:
    print("DMA transfer complete")
else:
    print("DMA transfer is still active:", d.active())
print(b)
d.close()

[mungewell]

Update script now works on both RP2040 and RP2350. Feed GPS 1PPS into GPIO16.
nudge.py.txt

Gives:

MPY: soft reboot
Running on RP2350
CPU Freq: 256000000
Setting up StateMachines
Setting up DMA
Nudge-Lock Success
Starting last StateMachine, so it syncs to 1us tick
Shutdown 2nd SM, reconfigure and restart
Pin timestamped by 1us at 0x22668218
Pin timestamped by PIO at 0x0401c15b 0 0x5b
Correlating 0x55555554

Pin timestamped by 1us at 0x2274a95c
Pin timestamped by PIO at 0x0ba2e1dd 1 0x5d
Correlating 0xaaaaaaa9

Pin timestamped by 1us at 0x2283eb9d
Pin timestamped by PIO at 0x13440260 0 0x60
Correlating 0x55555553

...

Pin timestamped by 1us at 0x22df7923
Pin timestamped by PIO at 0x410ac574 0 0x74
Correlating 0x555554ff <--- until lowest 'X' bits are the same

Pin timestamped by 1us at 0x22eebb64
Pin timestamped by PIO at 0x48abe5f9 1 0x79
Timestamp: 586070884.9453125

Pin timestamped by 1us at 0x22fdfda6
Pin timestamped by PIO at 0x504d067d 0 0x7d
Validation failed, DMA late? <--- ie lowest bits don't follow correlation
Timestamp: 587070885.9765625

Pin timestamped by 1us at 0x230d3fe7
Pin timestamped by PIO at 0x57ee2702 0 0x02
Timestamp: 588070887.015625

Pin timestamped by 1us at 0x231c8228
Pin timestamped by PIO at 0x5f8f4787 1 0x07
Timestamp: 589070888.0546875