W linii a poza linią
W Energetika-VDS programowanie oprogramowania odbywa się na naszej linii za pomocą dedykowanych stanowisk programujących. Gdy plan testów klienta wymaga testu funkcjonalnego, jednostka przechodzi do partnera FCT z już wgranym oprogramowaniem. AOI jest realizowane wewnętrznie dla każdej płytki; FCT jest zlecane na zewnątrz.
Niektórzy producenci łączą programowanie z testem funkcjonalnym w jednym stanowisku, więc płytka jest umieszczana raz, najpierw odbywa się programowanie, a następnie test. Działa to, gdy obie czynności są wykonywane w tym samym budynku. W naszej konfiguracji programowanie i FCT są fizycznie rozdzielone: realizujemy programowanie w linii, a partner FCT przeprowadza sekwencję funkcjonalną na świeżo zaprogramowanym oprogramowaniu.
Dla produktów bez testu funkcjonalnego w zakresie, zaprogramowana płytka jest wysyłana po AOI bez dodatkowej bramki testowej.
Interfejsy programowania
Interfejs do układu scalonego zależy od rodziny układu:
- SWD: ARM Cortex-M, mała liczba pinów, szybki
- JTAG: starsze ARM, FPGA, również debugowanie dla wielu układów
- UART: programowanie bootloaderowe, wolniejsze, lecz bez dodatkowych pinów
- USB-DFU: układy z USB, płytka działa jako urządzenie USB podczas programowania
- I2C, SPI: rzadziej stosowane, używane dla niektórych EEPROM i elementów bezpiecznych
Większość programowań produkcyjnych używa SWD dla urządzeń ARM Cortex-M i JTAG dla starszych lub o większej liczbie pinów.
Programowanie wieloobrazowe
Urządzenie połączone zazwyczaj posiada więcej niż jeden obraz oprogramowania:
- Bootloader: mały, podpisany, niezmienny po produkcji
- Aplikacja: główne oprogramowanie, możliwa aktualizacja OTA
- System plików: konfiguracja, zasoby webowe, magazyn certyfikatów
- Partycja produkcyjna: kalibracja jednostkowa, tożsamość, dane fabryczne
Programowanie po stronie produkcji zapisuje każdy obraz sekwencyjnie, we właściwej partycji, z odpowiednim podpisem, jeśli dotyczy.
Podpisane łańcuchy bootloaderów
Podpisany bootloader weryfikuje podpis aplikacji przed jej uruchomieniem. Sam bootloader jest podpisany przez mechanizm bezpiecznego rozruchu układu (skrót zapisany w eFuse, weryfikacja oparta na ROM).
Efekt: atakujący nie może zastąpić aplikacji dowolnym kodem, ponieważ bootloader odmówi jej uruchomienia. Atakujący nie może zastąpić bootloadera, ponieważ układ odmówi uruchomienia niepodpisanego bootloadera.
Po stronie produkcji oznacza to:
- Klucz podpisywania bootloadera wygenerowany i przechowywany w HSM
- Klucz podpisywania aplikacji wygenerowany i przechowywany w HSM
- Linia produkcyjna uzyskuje dostęp do podpisywania przez API, nigdy nie przechowuje klucza prywatnego
- eFuse spalony w celu zablokowania podpisu bootloadera
Tolerancja na utratę zasilania
Sekwencje programowania muszą tolerować utratę zasilania w trakcie. Typowy wzorzec: najpierw zapisz bootloader w stałym miejscu, zapisz aplikację w osobnym obszarze, ustaw flagę „ważny" w NVS dopiero po weryfikacji. Jeśli zasilanie zostanie przerwane w trakcie zapisu, bootloader zobaczy brakującą flagę i powróci do sprawnego oprogramowania (lub odmówi uruchomienia, w zależności od przyjętej polityki).
Weryfikacja
Po zapisie odczytaj z powrotem zaprogramowany obraz i oblicz jego skrót. Porównaj z oczekiwanym skrótem. Jeśli różni się, oznacz jednostkę jako błąd programowania i skieruj do naprawy.
Wykrywa to rzadki przypadek, gdy zapis się powiódł, lecz układ zapisał nieprawidłowe dane.
Logowanie jednostkowe
Po pomyślnym programowaniu zaloguj:
- Wersję oprogramowania
- Skrót oprogramowania
- Referencję klucza podpisywania
- Znacznik czasu programowania
- Numer seryjny jednostki
Dane te są przechowywane w produkcyjnej bazie danych identyfikowalności. Kupujący może później sprawdzić: „jakie oprogramowanie zostało wysłane z numerem seryjnym XXX, podpisane jakim kluczem".