Programlama / Üretim Akışı
Bu sayfa, B107AA R6 ana işlemcisinin (ATmega2560) programlanma yöntemini ve seri üretimde izlenecek güvenli/tekrarlanabilir akışı tanımlar. Amaç; sahada güncellenebilirlik (FOTA), üretimde hız ve izlenebilirlik (traceability) ve her cihazın tekil kimliklendirilmesidir.
Programlama yöntemleri
ICSP / ISP
B107AA’da ana işlemciyi ICSP/ISP (SPI üzerinden In‑System Programming) ile programlıyoruz. JTAG kullanmıyoruz.
ICSP; MCU’yu reset hattından programlama moduna alır ve MOSI/MISO/SCK üzerinden flash yazımı yapar. Seri üretimde en deterministik ve düşük riskli yöntem budur; çünkü cihazın kendi haberleşme katmanlarına (GSM vb.) bağlı değildir.
Tipik sinyaller:
- MOSI (Programlayıcı → MCU)
- MISO (MCU → Programlayıcı)
- SCK
- RESET
- VCC (hedef besleme)
- GND
Üretimde programlama kablosu/fixture üzerinden harici 3V3 besleme verilir. Bunun amacı, programlama sırasında kartın normal güç yolunda yaşanabilecek kesinti, brown‑out veya gürültünün “yarım yazım” riskini artırmasını engellemektir. Fixture tarafında akım limitli ve kararlı bir 3V3 kaynağı kullanılması önerilir.
Bootloader (MegaCore)
Ana işlemci üzerinde bootloader olarak MegaCore kullanıyoruz:
- Repo:
https://github.com/MCUdude/MegaCore
MegaCore’un bu projede tercih edilmesinin nedeni; AVR tarafında küçük footprint, stabil çalışma ve üretim/servis süreçlerinde pratik bir güncelleme/geri yükleme opsiyonu sunmasıdır. Bootloader, üretimde temel yöntem olan ICSP’nin yerine geçmez; ancak sahada/serviste kontrollü senaryolarda yardımcı bir katman olarak değerlidir.
Sahada güncelleme
İlk üretimde firmware, fiziksel programlama kablosu üzerinden ICSP ile yüklenir.
Sahada ise firmware güncelleme stratejisi “bootloader ile manuel yükleme” değil; sistem mimarisinde tanımlanan FOTA akışıdır. (FOTA detayları ilgili bölümde ayrıca anlatılmıştır.)
Ana işlemci programlama soketi
B107AA üzerinde ana işlemci programlamak için kullanılan soket/konnektör, üretim ve servis süreçlerinde tek giriş noktasıdır. Bu soket üzerinden:
- İlk firmware yüklemesi,
- Fuse/lock bit konfigürasyonu,
- Servis durumunda yeniden yazılım atma
işlemleri yapılır.
Önerilen pinout (AVR‑ISP)
Aşağıdaki pin dizilimi, endüstride yaygın 2×3 AVR‑ISP standardıyla uyumludur:
| Pin | Sinyal | Açıklama |
|---|---|---|
| 1 | MISO | MCU → Programlayıcı |
| 2 | VCC | Hedef referans / opsiyonel besleme |
| 3 | SCK | SPI clock |
| 4 | MOSI | Programlayıcı → MCU |
| 5 | RESET | Programlama moduna alma |
| 6 | GND | Referans toprak |
Eğer kart üzerinde farklı bir soket/konnektör kullanılıyorsa (ör. tek sıra header veya test pad grubu), üretim fixture’ı bu pinlerin mantıksal eşleşmesini sağlamak zorundadır.
Bu projede programlama sırasında VCC hattı üzerinden hedef karta harici 3V3 verilir. Böylece kartın normal güç yolunda (adaptör/batarya/şarj) oluşabilecek geçici dalgalanmalar programlama sürecini etkilemez.
Seri üretim akışı
Seri üretimde hedef; operatör hatalarını azaltan, “tek fixture → otomatik adımlar” yaklaşımıdır. Üretim akışı şu sırayla önerilir:
“Factory Test” Firmware
Modül Çin’de üretildiğinde, nihai ürün firmware’inden bağımsız olarak yalnızca temel donanım bileşenlerinin çalıştığını hızlıca doğrulayabilmek için özel bir Factory Test firmware’i kullanıyoruz.
Bu firmware’in amacı:
- üretim hattında kısa sürede “kart çalışıyor mu?” kararını vermek,
- kritik blokların (MCU, 3V3, I2C, SD, temel IO vb.) minimum fonksiyon testini yapmak,
- sonucu operatöre ana işlemci LED’i üzerinden anlaşılır biçimde bildirmektir.
LED tabanlı durum bildirimi
Factory Test firmware’i, test sonucuna göre ana işlemci LED’ini farklı renk/kalıplarla yakar.
- Yeşil: temel testler OK
- Turuncu: I2C hatası (örnek)
- Mavi: SD kart algılanmadı (örnek)
Not: Renk/pattern haritası ve test kapsamı şu an taslak seviyededir; netleştirildiğinde bu bölüm, üretim partnerine verilecek “Test Prosedürü” dokümanı ile birebir senkron olacak şekilde güncellenecektir.
Bu firmware ve LED anlamları, Çin üretim partnerimize ayrıca doküman olarak verilecek ve üretim fixture akışının bir parçası olacaktır.
Fixture önerisi
Üretim hızını belirleyen en önemli faktör, kartı hızlı ve hatasız temas ettirmektir.
- Pogo‑pin fixture (bed‑of‑nails): Seri üretim için en verimli yöntem.
- Programlama hatları (MISO/MOSI/SCK/RESET/VCC/GND) için test pad ayrılmalı.
- Test pad’ler mümkünse aynı bölgede ve mekanik olarak erişilebilir yerleşmeli.
- Reset hattı ve SPI hatları, fixture sırasında uzun kablo ile taşınacağı için EMI’ye açık olabilir; bu nedenle fixture kablo boyu kısa tutulmalı ve GND referansı sağlam olmalıdır.
Üretim hattında “Factory Test firmware” yazımı ve LED doğrulaması, pogo‑pin fixture ile birkaç saniyede tamamlanabilecek şekilde tasarlanmalıdır. Nihai firmware yazımı, bu doğrulamadan sonra yapılmalıdır.
Üretim sırasında önerilen güvenlik ayarları
Fuse/lock bit ayarları, cihazın saat kaynağı (7.3728 MHz harici kristal), brown‑out politikası ve servis güvenlik yaklaşımına göre belirlenir. Aşağıdaki öneriler “başlangıç noktası”dır; seri üretime girmeden önce test fixture’ı üzerinde doğrulanmalıdır.
Fuse önerileri (ATmega2560, 3V3 + harici kristal):
- CKSEL/SUT: Harici kristal/rezonatör modunda güvenli startup (kristalin oturması için yeterli SUT)
- CKDIV8: Kapalı (CPU frekansının bölünmemesi)
- BODLEVEL: 3V3 sistem için tipik seçim ~2.7V (brown‑out’ta deterministik reset)
- BOOTRST/BOOTSZ: Bootloader kullanılıyorsa reset vektörü boot alanına yönlendirilir ve boot alan boyutu seçilen bootloader’a göre ayarlanır.
- JTAGEN: Kullanılmadığı için kapalı tutulması önerilir (IO pinlerini serbest bırakır).
- SPIEN: ISP programlama için aktif kalmalıdır.
- RSTDISBL: Reset pini devre dışı bırakılmamalıdır (servis/üretim için kritik).
Lock bit önerisi:
- Bootloader ve uygulama alanı için “okuma koruması” seviyeleri, ürün güvenlik politikasıyla seçilmelidir.
- Sahada servis kolaylığı hedefleniyorsa daha yumuşak, fikri mülkiyet koruması hedefleniyorsa daha sıkı lock bit tercih edilir.
Bu sayfada kesin hex fuse değerleri vermekten kaçınıyoruz; çünkü tek bir bit hatası cihazı ISP ile kurtarmayı zorlaştırabilir. Kesin değerler, firmware repo’sunda build çıktılarıyla birlikte versiyonlanmalı ve üretim prosedürüne otomatik adım olarak eklenmelidir.
Firmware versiyonlama
Sahada yönetilebilirlik için firmware versiyonlama yalnız “v1.2.3” yazmak değildir; cihazın çalışırken raporladığı kimlik bilgileri, server tarafında doğru teşhis için zorunludur.
Önerilen versiyon alanları:
- SemVer:
MAJOR.MINOR.PATCH - Git commit kısa hash: build’in kaynağı
- Build tarihi (UTC)
- Hardware revision: ör.
B107AA-R6
Firmware, bu bilgileri:
- Telemetri paketinde (periyodik veya event bazlı)
- ve/veya cihazın servis ekranında/komut yanıtında
göndermelidir.
Device ID ile ilişkilendirme
Cihazın tekil kimliği, sahada “hangi cihaz konuşuyor?” sorusunun cevabıdır. Bu projede Device ID, yalnız yazılımsal bir seri numara değil; donanımsal bir kimlikten türetilmelidir.
DS28C rolü
DS28C ailesi (I2C üzerinde güvenli kimlik/doğrulama elemanı) cihaz başına tekil bir kimlik sağlayabilir. Üretim akışında önerilen yaklaşım:
- DS28C’den tekil ID okunur (fixture/test adımında).
2 Bu ID, üretim kaydıyla eşleştirilir:
- PCB seri no / lot
- IMEI/ICCID (modem/SIM)
- üretim tarihi
- Server tarafında cihaz kaydı bu ID üzerinden açılır.
Kritik prensip: Firmware versiyonu değişebilir, IMEI/SIM değişebilir; ama DS28C gibi donanımsal kimlik sabit kalır. Bu, cihazın kimliklendirilmesini “güvenilir” kılar.
Firmware ile kullanım
Firmware tarafında DS28C ID;
- ilk boot’ta okunup RAM’de tutulabilir,
- telemetri paketlerine eklenebilir,
- cihaz kayıt/güvenlik akışında (challenge‑response varsa) kullanılabilir.
Bu sayede sahada “yanlış cihazla eşleşme” riski düşer ve üretim izlenebilirliği artar.
Ek notlar
- Programlama soketi kutu içinde erişilebilir tutulmalı (servis senaryoları).
- Fixture/test akışında watchdog devresi (MAX6369) nedeniyle istenmeyen reset döngüsü yaşanırsa, tasarımda bulunan servis linkleri (örn. 0R köprü) üretim prosedüründe tanımlanmalıdır.
- Üretim log’larının saklanması (hangi firmware, hangi DS28C ID, hangi tarih) sahada geri çağırma (recall) ve hata analizi için kritik olacaktır.