3. backup - > bundan önce, göreceli stabil çalışan baseline. • Şimdilik büyük refactor yapmadan, software’de şu küçük önlemleri öneririm: 1. Drop logunu doğrulama noktası yap RF kesince mutlaka şu tarz log görmeliyiz: tracking channel X drop status=... tracking channel X has dropped Bu geliyorsa RTL fix iş görüyor demektir. 2. Nav solve için minimum guard ekle Nav solve öncesi sadece şu koşulları sağlayan kanalları kullan: - software node var, - tracking IP BUSY=1, - tracking IP LOCK=1, - STOP_UNLOCK flag yok, - subframe/ephemeris yeterli, - measurement fresh. 3. Orphan nav solve interrupt’ı sessiz toparla get_element_by_ip_number() NULL dönerse sürekli error basmak yerine: - slot’u temizle, - nav-bit mode’a al, - log’u rate-limit et. Bunu kısmen yapmıştık; korunmalı. 4. Drop gelince ölçümü hemen stale yap Sadece linked-list node silmek değil, ilgili PRN/IP için nav solve input’u da anında invalid olmalı. Böylece aynı döngüde eski measurement kullanılmaz. 5. Printf’i azalt 500 ms nav solve periodda ISR içindeki sürekli log sistemi yavaşlatır. NAV SOLVE PERIOD, address, status gibi loglar debug-level veya rate-limit altında olmalı. 6. Nav solve snapshot kullan Solve başlamadan önce aktif kanalları küçük bir array’e kopyala. Solve sırasında linked list değişirse hesap etkilenmesin. 7. Duplicate PRN/IP kontrolü Yeni acquisition sonucu tracking’e atanırken aynı PRN başka bir busy IP’de mi kontrol et. Varsa yeni atama yapma veya eski slot’u temizle. 8. RF kopma testi için sayaç ekle Debug amaçlı: - drop_count - nav_solve_count - orphan_nav_solve_count - reacquire_count Bunları UART’ta sürekli değil, belirli aralıkla özet basmak daha iyi. Kısa hali: büyük OS-style refactor’u şimdilik ertele. Yeni RTL ile RF drop/ reacquire doğruysa software’de sadece freshness guard + log azaltma + duplicate/orphan temizliği yeterli olur. ------------------------------------------------------------------------------- 4. backup -> 3 un ustune memory leak lar gıderıldı. adres sanitizer c++ ın uzerıne › neler yaptık ? • gps_system içinde memory leak taraması yaptık. Önce malloc/free/create_matrix/free_matrix kullanımını inceledik. Leak’in linked-list tarafında değil, nav çözümü tarafında olduğunu bulduk: src/ NavEquations.c:451 içinde oluşturulan TA, ATA, invATA, invATA_Left matrixleri, convergence durumunda break ile çıkınca free edilmiyordu. Bunu Linux GCC sanitizer ile /tmp/gps_linux_gcc altında doğruladık. LeakSanitizer önce şunu verdi: 816 byte(s) leaked in 28 allocation(s) Sonra orijinal kodu patchledik: src/NavEquations.c:493 free_matrix(TA); free_matrix(ATA); free_matrix(invATA); free_matrix(invATA_Left); if(norm < 1e-4) { break; } Son kontroller: - Bare-metal make başarılı. - Linux -fsanitize=address,leak harness artık leak raporu vermiyor. - GCC -fanalyzer ile tekrar leak/use-after-free/double-free taraması yaptık; yeni leak bulmadı. Kalan not: leak temizlendi, ama malloc başarısız olursa bazı yerlerde null check eksik. Bu leak değil, heap tükenince crash riski.