In-line έναντι offline
Στην Energetika-VDS, το flashing firmware γίνεται στη γραμμή μας μέσω αποκλειστικών programming fixtures. Όταν το test plan του πελάτη απαιτεί functional test, η μονάδα προχωρά σε συνεργαζόμενο test house με το firmware ήδη φορτωμένο. Ο AOI εκτελείται εσωτερικά σε κάθε πλακέτα· το FCT προμηθεύεται εξωτερικά.
Ορισμένοι κατασκευαστές ενσωματώνουν το flashing στο ίδιο fixture με το functional test, ώστε η πλακέτα να τοποθετείται μία φορά και ο προγραμματισμός να εκτελείται πρώτος, μετά η δοκιμή. Αυτό λειτουργεί όταν και τα δύο βήματα γίνονται στο ίδιο κτίριο. Στη δική μας διάταξη, το flashing και το FCT είναι φυσικά διαχωρισμένα: εκτελούμε flashing in-line, και ο συνεργαζόμενος test house εκτελεί την functional ακολουθία στο μόλις προγραμματισμένο firmware.
Για προϊόντα χωρίς functional test στο πεδίο εφαρμογής, η flashed πλακέτα αποστέλλεται μετά τον AOI χωρίς πρόσθετη πύλη δοκιμής.
Διεπαφές προγραμματισμού
Η διεπαφή προς το τσιπ διαφέρει ανά οικογένεια τσιπ:
- SWD: ARM Cortex-M, λίγες ακίδες, γρήγορο
- JTAG: παλιά ARM, FPGA, επίσης debug για πολλά τσιπ
- UART: προγραμματισμός μέσω bootloader, πιο αργός αλλά χωρίς επιπλέον ακίδες
- USB-DFU: τσιπ με δυνατότητα USB, η πλακέτα λειτουργεί ως συσκευή USB κατά τον προγραμματισμό
- I2C, SPI: λιγότερο συνηθισμένα, χρησιμοποιούνται για ορισμένα EEPROM και secure elements
Οι περισσότεροι προγραμματισμοί παραγωγής χρησιμοποιούν SWD για συσκευές ARM Cortex-M και JTAG για παλαιότερα ή υψηλότερου αριθμού ακίδων εξαρτήματα.
Προγραμματισμός πολλαπλών εικόνων
Μια συνδεδεμένη συσκευή συνήθως έχει περισσότερες από μία εικόνες firmware:
- Bootloader: μικρό, υπογεγραμμένο, αμετάβλητο μετά την παραγωγή
- Εφαρμογή: κύριο firmware, OTA-updatable
- File system: ρυθμίσεις, web assets, αποθήκη πιστοποιητικών
- Manufacturing partition: βαθμονόμηση ανά μονάδα, ταυτότητα, factory data
Ο προγραμματισμός από πλευράς παραγωγής γράφει κάθε εικόνα διαδοχικά, στη σωστή partition, με τη σωστή υπογραφή όπου ισχύει.
Αλυσίδες υπογεγραμμένου bootloader
Ένας υπογεγραμμένος bootloader ελέγχει την υπογραφή της εφαρμογής πριν την εκκινήσει. Ο ίδιος ο bootloader είναι υπογεγραμμένος από τον μηχανισμό secure boot του τσιπ (hash αποθηκευμένο σε eFuse, επαλήθευση μέσω ROM).
Αποτέλεσμα: ένας επιτιθέμενος δεν μπορεί να αντικαταστήσει την εφαρμογή με αυθαίρετο κώδικα, διότι ο bootloader θα αρνηθεί να την εκκινήσει. Ένας επιτιθέμενος δεν μπορεί να αντικαταστήσει τον bootloader, διότι το τσιπ θα αρνηθεί να εκκινήσει μη υπογεγραμμένο bootloader.
Από πλευράς παραγωγής, αυτό σημαίνει:
- Κλειδί υπογραφής bootloader παράγεται και αποθηκεύεται σε HSM
- Κλειδί υπογραφής εφαρμογής παράγεται και αποθηκεύεται σε HSM
- Η γραμμή παραγωγής προσπελαύνει την υπογραφή μέσω API, δεν κατέχει ποτέ το ιδιωτικό κλειδί
- Καμένο eFuse που κλειδώνει την υπογραφή του bootloader στη θέση της
Ανοχή σε απώλεια ισχύος
Οι ακολουθίες προγραμματισμού πρέπει να ανέχονται απώλεια ισχύος κατά τη διάρκεια του flash. Συνηθισμένο μοτίβο: γράψιμο του bootloader πρώτα σε σταθερή θέση, γράψιμο της εφαρμογής σε ξεχωριστή περιοχή, ορισμός σημαίας "valid" στο NVS μόνο μετά την επαλήθευση. Αν η ισχύς πέσει κατά το γράψιμο, ο bootloader βλέπει την απουσία της σημαίας valid και επιστρέφει σε γνωστό-καλό firmware (ή αρνείται να εκκινήσει, ανάλογα με την πολιτική).
Επαλήθευση
Μετά την εγγραφή, διαβάζετε ξανά τη flashed εικόνα και υπολογίζετε το hash της. Συγκρίνετε με το αναμενόμενο hash. Αν διαφέρει, σημειώστε τη μονάδα ως αποτυχία flashing και δρομολογήστε για rework.
Αυτό εντοπίζει τη σπάνια περίπτωση όπου η εγγραφή επιτυχάνει αλλά το τσιπ γράφει κατεστραμμένα δεδομένα.
Καταγραφή ανά μονάδα
Μετά από επιτυχημένο flash, καταγράφονται:
- Έκδοση firmware
- Hash firmware
- Αναφορά κλειδιού υπογραφής
- Χρονοσήμανση προγραμματισμού
- Σειριακός αριθμός ανά μονάδα
Αυτά τα δεδομένα βρίσκονται στη βάση ιχνηλασιμότητας παραγωγής. Ο αγοραστής μπορεί να ρωτήσει αργότερα: "τι firmware στάλθηκε στον σειριακό XXX, υπογεγραμμένο με ποιο κλειδί".