From 0f6b3482c5e8604a15d25ef450108b2db128a986 Mon Sep 17 00:00:00 2001 From: onur Date: Sat, 25 Jul 2026 13:32:24 +0300 Subject: [PATCH] docs(pps): record live lock diagnosis --- hardware/external/gps/rtl/pps/README.md | 21 ++++++++++++++++ soc/software/fusion/README.md | 33 ++++++++++++++++++++++++- 2 files changed, 53 insertions(+), 1 deletion(-) diff --git a/hardware/external/gps/rtl/pps/README.md b/hardware/external/gps/rtl/pps/README.md index 535cdbd..cf52cdc 100644 --- a/hardware/external/gps/rtl/pps/README.md +++ b/hardware/external/gps/rtl/pps/README.md @@ -83,6 +83,27 @@ software polls `STATUS.DIAG_BUSY` before reading the group. The disciplined timebase continues in holdover and while the physical output is disabled; `CONTROL.ENABLE` gates `pps_out` and validity, not timekeeping. +This also applies to the single-word `ACTIVE_SEQUENCE` and `PULSE_COUNT` +registers: they belong to the same frozen diagnostic group. A live debugger +must halt the CPU briefly, request a new snapshot, wait for status bit 10 to +clear, and only then read `0x48..0x74`. For example, with OpenOCD's GDB monitor: + +```gdb +monitor halt +monitor mww 0x1002a078 1 +monitor sleep 10 +x/wx 0x1002a004 +x/wx 0x1002a048 +x/wx 0x1002a05c +x/wx 0x1002a060 +x/wx 0x1002a074 +monitor resume +``` + +Reading `ACTIVE_SEQUENCE` or `PULSE_COUNT` without this request can return the +previous snapshot, including reset zero, even while the core is accepting +commits and generating pulses. + Run lint plus both unit-level Questa tests from this directory: ``` diff --git a/soc/software/fusion/README.md b/soc/software/fusion/README.md index a760988..019d953 100644 --- a/soc/software/fusion/README.md +++ b/soc/software/fusion/README.md @@ -163,14 +163,24 @@ ulaşmaz. Genesys2 post-route checkpoint kontrolünde `gps_pps` portunun `JC10/AK28`, LVCMOS33 olarak yerleştiği, sabit 0/1'e bağlanmadığı ve PPS core `pps_out_p_reg/Q` tarafından sürüldüğü doğrulandı. Canlı ayrım için çalışan -kartta GDB ile şu register'lar okunmalıdır: +kartta CPU kısa süre durdurulmalı ve önce atomik diagnostic snapshot +istenmelidir. `ACTIVE_SEQUENCE`, faz/integrator/rate ve `PULSE_COUNT` aynı +donmuş snapshot grubundadır; `DIAG_SNAPSHOT` yazılmadan okunurlarsa core +çalışırken bile eski veya reset sıfırı görülebilir: ```gdb +monitor halt x/wx 0x1002a07c x/wx 0x1002a000 x/wx 0x1002a004 +monitor mww 0x1002a078 1 +monitor sleep 10 +x/wx 0x1002a004 x/wx 0x1002a048 +x/wx 0x1002a05c +x/wx 0x1002a060 x/wx 0x1002a074 +monitor resume ``` | Register | Beklenen/yorum | @@ -187,6 +197,27 @@ lock acquisition/faz jitter'ıdır. `STATUS` lock gösteriyor ve `PULSE_COUNT` artıyorsa JC10 sinyali JC11 GND referansıyla osiloskop veya logic analyzer'da ölçülmelidir; pulse saniyede bir yaklaşık 100 ms HIGH'dır. +2026-07-25 canlı Genesys2 ölçümünde `VERSION=0x00020100`, +`CONTROL=0x00000003` ve snapshot `ACTIVE_SEQUENCE=11583` görüldü. +`PULSE_COUNT=314`, PPS core'un resetten beri 314 `pps_out` pulse olayı +oluşturduğunu kanıtladı; post-route top-level yol da sabit LOW değildir. +Bu iki kanıt pinin elektriksel seviyesi için prob ölçümünün yerini tutmaz. +Ölçüm anında lock yoktu. Debugger'ın uzun halt etkisi temizlenip sticky bayraklar +sıfırlandıktan sonra 50 saniye boyunca status hatasız `0x00000007` +(enabled/aligned/tracking, unlocked) kaldı; pulse count artmadı. Üç ayrı +snapshot faz hatası yaklaşık `+1.95 us`, `+1.35 us` ve `-0.58 us` verdi. +Bunların tamamı beş ardışık update için gereken `+/-64 ns` acquire +penceresinden büyüktür. + +Aynı koşudaki beş uydulu çözümlerde `GDOP` yaklaşık 17 ve `TDOP` yaklaşık +10.5'ti; ham GPS konum/irtifa da onlarca-yüzlerce metre oynuyordu. Bu zayıf +geometri ve WLS clock-bias gürültüsü, ölçülen mikrosaniye seviyesindeki PPS +faz oynaklığıyla uyumludur. Dolayısıyla mevcut kart bulgusu bir pin veya +APB/CDC kopukluğundan çok timing-observation kalite/lock-gating problemine +işaret eder. Eşik ölçümsüz büyütülmemeli; önce clock-bias/TDOP kalite kapısı, +outlier reddi veya faz gözlemi süzme stratejisi board A/B testiyle +değerlendirilmelidir. + ## Çalıştırma UART kaydı: