Aufgaben in der Fabrik
Wichtig
Dies ist die Dokumentation zu Azure Sphere (Legacy). Azure Sphere (Legacy) wird am 27. September 2027 eingestellt, und Benutzer müssen bis zu diesem Zeitpunkt zu Azure Sphere (integriert) migrieren. Verwenden Sie die Versionsauswahl oberhalb des Inhaltsverzeichniss, um die Dokumentation zu Azure Sphere (Integriert) anzuzeigen.
Die Herstellung verbundener Geräte, die Azure Sphere-Hardware enthalten, umfasst die folgenden Werksaufgaben, um Geräte für den Versand vorzubereiten:
- Verbinden der einzelnen Azure Sphere-Chip mit einem Werksboden-PC
- Abrufen von Gerätedetails und Aufzeichnen von Gerätedetails zur späteren Verwendung
- Aktualisieren des Azure Sphere-Betriebssystems bei Bedarf
- Aktualisieren Des vertrauenswürdigen Schlüsselspeichers bei Bedarf
- Laden von Software auf das Gerät
- Ausführen von Funktionstests, um den korrekten Betrieb des Produkts zu überprüfen
- Durchführen von Funkfrequenztests und -kalibrierungen
- Überprüfen der WLAN-Kommunikation
- Konfigurieren des Geräts für Ethernet
- Abschließen des Azure Sphere-Geräts für den Versand
Sie müssen den Chip zuerst mit dem PC verbinden, Gerätedetails zweitens abrufen und das Gerät zuletzt abschließen, aber Sie können die anderen Aufgaben in jeder Reihenfolge ausführen, die ihrer Fertigungsumgebung entspricht.
Wichtig
Sie sollten einige Vorbereitungen durchführen, um sicherzustellen, dass Ihre Werksaufgaben ohne Verzögerungen abgeschlossen werden können. Die Vorbereitung umfasst die Einrichtung des Werksboden-PCs und alle anderen erforderlichen Geräte und die Installation der erforderlichen PC-Softwaretools. Alle Aufgaben, die Sie tun sollten, um sich auf einen reibungslosen Herstellungsprozess vorzubereiten, werden in der Herstellungsprozessvorbereitung beschrieben.
Verbinden sie jeden Azure Sphere-Chip mit einem Werksboden-PC
Während der Herstellung müssen Sie jeden Azure Sphere-Chip mit einem Werksboden-PC verbinden. Wenn Sie mehrere Azure Sphere-Geräte gleichzeitig mit einem einzelnen PC verbinden möchten, lesen Sie "Equipment for factory-floor tasks " in den Fertigungsvorbereitungsaufgaben.
Die meisten Werksaufgaben umfassen den Azsphere-Gerätebefehl. Wenn Sie mehrere Geräte an den PC angeschlossen haben, müssen Sie das Gerät angeben, auf dem der Azsphere-Gerätebefehl angewendet werden soll, indem Sie den --device Parameter einschließen, der entweder auf die IP-Adresse des Geräts oder den Verbindungspfad des Geräts festgelegt ist. Der Befehl schlägt fehl, wenn der --device Parameter weggelassen wird und mehrere Geräte angefügt sind. Informationen zum Abrufen der IP-Adresse oder des Verbindungspfads finden Sie unter Abrufen von Gerätedetails.
Wichtig
Die Azure Sphere 23.05 SDK-Version und spätere Versionen unterstützen die Kommunikation mit mehreren angeschlossenen Geräten unter Windows und Linux.
Abrufen von Gerätedetails
Sie müssen die Geräte-ID jedes Azure Sphere-Chips aufzeichnen, den Ihr Unternehmen in hergestellte Produkte integriert. Sie benötigen die Geräte-ID für Cloudkonfigurationsaufgaben.
Wenn Sie über mehrere Geräte verfügen, die an den Werksboden-PC angeschlossen sind, müssen Sie auch die IP-Adresse oder den Verbindungspfad der angeschlossenen Geräte aufzeichnen, um sie später in Werksaufgaben zu verwenden. Wie unter "Verbinden jedes Azure Sphere-Chips" erläutert, ist die IP-Adresse oder der Verbindungspfad erforderlich, um das Zielgerät anzugeben, wenn mehrere angeschlossene Geräte vorhanden sind.
Um die Geräte-ID, DIE IP-Adresse und den Verbindungspfad der angeschlossenen Geräte abzurufen, verwenden Sie den befehl "azsphere device list-attached ". Die folgenden Beschreibungen enthalten wichtige Details zu geräte-ID, IP-Adresse und Verbindungspfad.
Geräte-ID – Der Siliziumhersteller erstellt die Geräte-ID, speichert sie auf dem Chip und registriert sie bei Microsoft. Mit dieser Geräteregistrierung wird sichergestellt, dass Microsoft über alle Azure Sphere-Chips informiert ist und dass nur legitime Chips in verbundenen Geräten genutzt werden können.
IP-Adresse – Die IP-Adresse wird zugewiesen, wenn eine FTDI-basierte Geräteschnittstelle an den PC angeschlossen ist; es weist nicht darauf hin, dass ein reaktionsfähiges Gerät vorhanden ist. Die IP-Adresse bleibt erhalten, während die FTDI-basierte Geräteschnittstelle an den PC angeschlossen ist, auch wenn ein anderes Azure Sphere-Gerät mit der Schnittstelle verbunden ist. Nach einem Neustart des PCs kann sich die IP-Adresse jedoch ändern. Die erste FTDI-basierte Geräteschnittstelle, die angefügt werden soll, wird der Adresse 192.168.35.2 zugewiesen. Jedem Gerät wird eine IP-Adresse zugewiesen (auch wenn es nicht reagiert), sodass Sie anhand der IP-Adresse ein Gerät identifizieren können, das wiederhergestellt werden muss.
Verbindungspfad – Der Verbindungspfad ist eine FTDI-Standort-ID , die die USB-Verbindung identifiziert. Die Standort-ID wird beibehalten, während die FTDI-basierte Geräteschnittstelle an den gleichen USB-Anschluss auf demselben USB-Hub angeschlossen ist, und wiederum an den gleichen Port auf dem PC. Daher wird er über einen Neustart hinweg beibehalten. Änderungen in der Verkabelung zwischen dem PC und dem Gerät können jedoch zu Änderungen am Verbindungspfad führen. Wie die IP-Adresse ändert er sich selbst dann nicht, wenn ein anderes Azure Sphere-Gerät an die FTDI-Schnittstelle angeschlossen wird.
Aktualisieren des Azure Sphere-Betriebssystems
Auf jedem Azure Sphere-Chip ist das Azure Sphere-Betriebssystem geladen, wenn dieser vom Chiphersteller ausgeliefert wird. Je nach Version des Azure Sphere-Betriebssystems auf den Chips, die bei Ihrem Zulieferer erhältlich sind, und den Anforderungen an die Betriebssystemversion für Ihre Anwendung müssen Sie das Azure Sphere-Betriebssystem während der Herstellung des verbundenen Geräts unter Umständen aktualisieren. Sie können das Betriebssystem aktualisieren, indem Sie bestimmte Wiederherstellungsimages installieren, die bereits auf Ihrem PC vorhanden sein sollten. Siehe Vorbereiten einer Aktualisierung des Betriebssystems in den Herstellungsvorbereitungsaufgaben. Die Fertigungsbeispiele enthalten ein Beispielskript, das parallele Wiederherstellung mit mehreren Geräten durchführt.
Sie können das Betriebssystem auf dem Azure Sphere-Gerät aktualisieren, indem Sie den Befehl "Azsphere Device Recover " ausgeben. Verwenden Sie den --images Parameter, um bestimmte Wiederherstellungsimages zu installieren:
azsphere device recover --images <path-to-images> [--device <IP-address or connection-path>]
Hinweis
Wenn mehrere Geräte mit dem PC verbunden sind, schließen Sie den --device Parameter ein, um das Zielgerät anhand der IP-Adresse oder des Verbindungspfads zu identifizieren. Weitere Informationen finden Sie unter "Verbinden jedes Azure Sphere-Chips mit einem Fabrikboden-PC ".
Aktualisieren des vertrauenswürdigen Schlüsselspeichers
Als Voraussetzung zum Laden von Software auf Ihrem Gerät müssen Sie möglicherweise den vertrauenswürdigen Schlüsselspeicher auf dem Gerät aktualisieren. Dies ist nur erforderlich, wenn das Betriebssystem auf dem Gerät älter als Ihre Software ist, und nur, wenn der von AS3 verwendete Azure Sphere-Imagesignaturschlüssel zwischen dem veröffentlichten Betriebssystem und Ihrer Software, die produktionssigniert ist, aktualisiert wurde. Um diesen Schritt zu vermeiden und die Fertigungszeit zu verringern, sollten Sie die Betriebssystemversion aktualisieren, die Sie während der Herstellung verwenden.
Sie können ganz einfach ermitteln, ob das Aktualisieren des vertrauenswürdigen Keystores erforderlich ist, indem Sie versuchen, Ihre Software gemäß den Anweisungen im nächsten Abschnitt zu laden. Wenn das Laden erfolgreich verläuft, müssen Sie den vertrauenswürdigen Schlüsselspeicher nicht aktualisieren. Wenn beim Laden ab der Nachricht Internal device error: Image not trusted by device ein Fehler auftritt, ist ein veralteter vertrauenswürdiger Schlüsselspeicher die Ursache.
Um den vertrauenswürdigen Schlüsselspeicher zu aktualisieren, müssen Sie die aktuelle vertrauenswürdige Schlüsselspeicherdatei erworben haben. Verwenden Sie dann als Teil Ihrer Fertigungsskripts den Befehl "azsphere device sideload deploy" zum Laden des aktualisierten vertrauenswürdigen Keystores vor dem Laden der Anwendungssoftware, und ersetzen <path-to-trusted-keystore.bin> Sie den Pfad zur vertrauenswürdigen Schlüsselspeicherdatei:
azsphere device sideload deploy --image-package <path-to-trusted-keystore.bin> [--device <IP-address or connection-path>]
Laden der Gerätesoftware
Alle Software, die Sie laden – unabhängig davon, ob es sich um ein Boardkonfigurationsimage, eine Testanwendung oder eine Produktionsanwendung handelt – müssen produktionssigniert sein. Wenn Sie eine temporäre Anwendung zum Testen laden, müssen Sie sie nach Abschluss des Tests löschen.
Alle produktionssignierten Bilder, die Sie während des Fabrikbodenprozesses benötigen, sollten vor Beginn des Prozesses auf Ihrem Werksboden-PC gespeichert werden, wie unter " Abrufen von produktionssignierten Bildern in den Herstellungsvorbereitungsaufgaben" beschrieben.
Bei der Herstellung darf es für Azure Sphere-Geräte nicht erforderlich sein, dass spezielle Gerätefunktionen installiert sein müssen, z. B. die appdevelopment-Funktion für das Debuggen. Die Einbindung von Funktionen für einzelne Geräte reduziert die Gerätesicherheit und erfordert eine Internetverbindung. Dies ist in der Fabrik normalerweise nicht wünschenswert.
Um Software auf ein Gerät in der Fabrik zu laden oder temporäre Software von einem Gerät zu löschen, nachdem der Test abgeschlossen ist, verwenden Sie den Azsphere Device Sideload-Befehl wie folgt:
Verwenden Sie azsphere device sideload deploy to load an image, ersetzen
<file-path>sie durch den Namen und pfad zu Ihrer produktionssignierten Imagedatei:azsphere device sideload deploy --image-package <file-path> [--device <IP-address or connection-path>]
Verwenden Sie das Querladen des Azsphere-Geräts, um ein temporäres Bild zu löschen, und ersetzen
<component-id>Sie dabei durch die Komponenten-ID des zu löschenden Bilds:azsphere device sideload delete --component-id <component-id> [--device <IP-address or connection-path>]
Hinweis
Wenn mehrere Geräte mit dem PC verbunden sind, schließen Sie den --device Parameter ein, um das Zielgerät anhand der IP-Adresse oder des Verbindungspfads zu identifizieren. Weitere Informationen finden Sie unter "Verbinden jedes Azure Sphere-Chips mit einem Fabrikboden-PC ".
Durchführen von Funktionstests
Funktionale Tests sind erforderlich, um zu überprüfen, ob das Produkt ordnungsgemäß funktioniert. Führen Sie die Anwendungen aus, die Sie im Rahmen der Herstellungsvorbereitungsaufgaben für funktionsbezogene Tests entwickelt haben. Weitere Informationen finden Sie unter Entwickeln von Anwendungen für Funktionstests.
Wenn Ihre Funktionstests eine Kommunikation mit dem getesteten Chip erfordern, verbinden Sie die MT3620-Peripherie-UARTs (ISU0, ISU1, ISU2 oder ISU3) entweder mit Ihrem Werksboden-PC oder externen Prüfgeräten über geeignete Schaltkreise Ihres eigenen Designs.
Durchführen von Funkfrequenztests und -kalibrierungen
Azure Sphere-Chips können wlan verwenden, um Softwareupdates zu erhalten und mit dem Internet zu kommunizieren. Wenn Ihr Produkt WLAN verwendet und entweder ein Chip-Down-Design oder ein Modul enthält, das nicht RF-zertifiziert ist, müssen Sie RF-Tests und Kalibrierungen für jedes Gerät durchführen. Die für diesen Vorgang benötigten Geräte und Werkzeuge werden in Der Ausrüstung und Software für RF-Tests und Kalibrierungen in den Herstellungsvorbereitungsaufgaben beschrieben.
Das RF-Tools-Paket enthält Dienstprogramme und eine C-API-Bibliothek für die Verwendung während des Tests. Sie können die C-API-Bibliothek verwenden, um produktspezifische RF-Einstellungen in E-Fuses zu programmieren. Beispielsweise werden E-Fuses so programmiert, dass die Antenne und Frequenz konfiguriert werden, um Geräte für eine optimale Leistung zu optimieren und WLAN-Kanäle zu aktivieren. Im Thema zu den Tools für Hochfrequenztests ist beschrieben, wie Sie die Hochfrequenztools verwenden.
Programm-E-Fuses zum Aktivieren von WLAN-Kanälen
Das Azure Sphere OS wählt WLAN-Kanäle basierend auf dem Regionscode aus, der in die MT3620 e-Fuses bei Offsetadressen 0x36 und 0x37 programmiert ist. Ausführliche Informationen zu E-Fuses auf dem MT3620 finden Sie im Mt3620 E-fuse Content Guidelines Mediatek-Dokument.
Der Regionscode ist ein ASCII-Code mit zwei Buchstaben. Das Azure Sphere-Betriebssystem verwendet die Regionscodeeinstellung in den E-Fuses, um die Region in der linux-drahtlosen Regulierungsdatenbank nachzuschlagen und dann die für diese Region zulässigen Kanäle auszuwählen. Wenn kein Regionscode in die E-Fuses programmiert ist, in diesem Fall bleiben die E-Fuses auf 0x00 0x00 festgelegt, oder wenn die Zeichen "00" programmiert sind, verwendet das Betriebssystem standardmäßig einen konservativen Satz von Kanälen, die in allen Regionen allgemein zulässig sind. Die für die Region "00" zulässigen Kanäle werden in der Linux Wireless-Regulierungsdatenbank angegeben.
Die Regionscodeeinstellung in den E-Fuses muss nicht mit dem Land übereinstimmen, in dem das Gerät verwendet wird. Hersteller können einen beliebigen Regionscode auswählen, der einer zulässigen Gruppe von Kanälen für die Region des Betriebs zugeordnet ist. In verschiedenen Regionen und Ländern werden häufig ähnliche oder identische Vorschriften erlassen, die die Verwendung von Regionscodes austauschbar ermöglichen können.
Beispiel: Um das Azure Sphere OS anzuweisen, WLAN-Kanäle für die Region "DE" (Deutschland), programm 0x44=D und 0x45=E in die E-Fuses unter Adressen 0x36 und 0x37 auszuwählen. Die zugelassenen Kanäle für Deutschland, aus der Linux Wireless Regulatory Database, werden unten gezeigt. Die meisten Länder in der Europäischen Union (EU) ermöglichen die gleichen Kanäle.
country DE: DFS-ETSI
(2400 - 2483.5 @ 40), (100 mW)
(5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
(5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
(5470 - 5725 @ 160), (500 mW), DFS, wmmrule=ETSI
# short range devices (ETSI EN 300 440-1)
(5725 - 5875 @ 80), (25 mW)
# 60 GHz band channels 1-4 (ETSI EN 302 567)
(57000 - 66000 @ 2160), (40)
Überprüfen der Hochfrequenzkonfiguration
Verwenden Sie rfSettingsTool, um zu überprüfen, ob die Funkkonfigurationsoptionen wie Zielübertragung, Regionscode und MAC-Adresse (Wi-Fi Media Access Control) korrekt festgelegt wurden. Die Dokumentation zum Tool für die Hochfrequenzeinstellungen enthält weitere Informationen zur Nutzung dieses Tools.
Überprüfen der WLAN-Kommunikation
Erwägen Sie die Verbindung mit einem WLAN-Zugriffspunkt, um zu überprüfen, ob Ihre Produktanwendung über WLAN kommunizieren kann. Stellen Sie sicher, dass die WLAN-Verbindung keinen Internetzugang hat, da ein Over-the-Air-Update auftreten kann, wenn der Chip eine Internetverbindung herstellt.
Um ein Gerät mit einem WLAN-Zugriffspunkt zu verbinden, folgen Sie den Anweisungen auf der Registerkarte "Schnellstart( CLI)". Wenn mehrere Geräte mit dem PC verbunden sind, müssen Sie den --device Parameter in den Befehl zum Anzeigen des Status des Azsphere-Geräts und den Befehl zum Hinzufügen des Azsphere-Geräts einschließen. Ausführliche Informationen zur Verwendung des Azsphere-Gerätebefehls mit mehreren angeschlossenen Geräten finden Sie unter Verbinden jedes Azure Sphere-Chips mit einem Werks-PC.
Nach dem WLAN-Test sollten Sie alle WLAN-Zugriffspunkte entfernen, die zum Testen vom Chip verwendet werden, damit diese für Kunden nicht sichtbar sind. Die Gerätewiederherstellung entfernt alle WLAN-Konfigurationsdaten vom Chip.
Konfigurieren des Geräts für Ethernet
Ein Azure Sphere-Gerät kann über Ethernet kommunizieren. Das Gerät erfordert einen externen Ethernet-Adapter und ein Boardkonfigurationsimage für die Kommunikation über Ethernet.
Um ein Azure Sphere-Gerät für Ethernet zu konfigurieren, verbinden Sie einen Ethernet-Adapter mit dem Azure Sphere-Gerät, wie unter Verbinden von Ethernet-Adaptern beschrieben.
Zwei Ethernet-Geräte werden vom Azure Sphere-Betriebssystem unterstützt.
- Microchip ENC28J60. Dies ist ein 10Base-T -Adapter (10 Mbps). Es kann mit einer LED-Anzeige mit halbduplexer Geschwindigkeit oder ohne LED-Indikator mit Vollduplexgeschwindigkeit verkabelt werden. Seeed devkits are kabeled for half-duplex operation.
- Wiznet W5500. Dies ist ein 100Base-TX -Adapter (100mpbs). Er unterstützt einen integrierten TCP/IP-Stapel und NIC-Pass-Through-Modi, azure Sphere unterstützt jedoch nur NIC-Pass-Through, wenn sie W5500 für die Internetverbindung verwenden. Aufgrund von Busbandbreiteneinschränkungen kann die volle Geschwindigkeit von 100 Mbps vom MT3620-Gerät nicht erreicht werden.
Die Ethernet-Schnittstelle wird automatisch aktiviert, sobald die Boardkonfiguration geladen wird, wie in der Load-Gerätesoftware beschrieben, und das Gerät wird neu gestartet. Für alle Schnittstellen werden standardmäßig dynamische IP-Adressen verwendet.
Fertigstellen des Azure Sphere-Geräts
Durch die Fertigstellung wird dafür gesorgt, dass sich das Azure Sphere-Gerät in einem geschützten Zustand befindet und für die Auslieferung an Kunden bereit ist. Sie müssen das Gerät fertigstellen, bevor Sie es ausliefern. Die Fertigstellung umfasst Folgendes:
Mit dem Durchführen von Prüfungen auf die Auslieferungsbereitschaft wird sichergestellt, dass die richtige Systemsoftware und Produktionsanwendung installiert und die Hochfrequenztools deaktiviert sind.
Festlegen des Herstellungszustands des Geräts, um die Tools für die Hochfrequenzkonfiguration und Kalibrierung zu sperren und Sicherheitsverletzungen zu verhindern
Ausführen von Ready-to-Ship-Prüfungen
Es ist wichtig, vor dem Versenden eines Produkts, das ein Azure Sphere-Gerät enthält, sofort einsatzbereite Prüfungen auszuführen. Für unterschiedliche Fertigungszustände müssen unterschiedliche Prüfungen durchgeführt werden. Fertige Versandkontrollen stellen Folgendes sicher:
- Der Geräteherstellungszustand wird für diese Phase der Fertigung ordnungsgemäß festgelegt.
- Das Azure Sphere-Betriebssystem auf dem Gerät ist gültig und die erwartete Version. Dies kann nur auf Geräte überprüft werden, die sich noch nicht im DeviceComplete-Zustand befinden.
- Vom Benutzer bereitgestellte Bilder auf dem Gerät stimmen mit der Liste der erwarteten Bilder überein. Dies kann nur auf Geräte überprüft werden, die sich noch nicht im DeviceComplete-Zustand befinden.
- Auf dem Gerät sind keine unerwarteten WLAN-Netzwerke konfiguriert. Dies kann nur auf Geräte überprüft werden, die sich noch nicht im DeviceComplete-Zustand befinden.
- Das Gerät enthält keine speziellen Funktionszertifikate. Bei MT3620-basierten Geräten kann dies nur auf Geräten überprüft werden, die sich nicht im Leeren Zustand befinden.
Unterschiedliche Prüfungen sind in verschiedenen Produktionsphasen erforderlich, da der Herstellungszustand des Geräts die Funktionen des Geräts bestimmt.
Welche Prüfungen Ausgeführt werden, hängt auch davon ab, ob Sie ein Modul oder ein verbundenes Gerät entwerfen. Als Modulhersteller können Sie z. B. den Chip im Zustand "Blank Manufacturing" verlassen, damit der Kunde des Moduls zusätzliche Funktests und Konfigurationen durchführen kann.
Verwenden von device_ready.py zum Durchführen von Prüfungen
Das Paket "Fertigungsbeispiele" enthält ein Tool namens device_ready.py, das die oben genannten Prüfungen nach Bedarf für jeden Herstellungszustand durchführt. Es sollte für jeden der Für Ihr Gerät relevanten Fertigungszustände ausgeführt werden.
In der folgenden Tabelle sind die Parameter aufgeführt, die vom skript device_ready.py verwendet werden:
| Parameter | Beschreibung |
|---|---|
--expected_mfg_state |
Bestimmt, auf welchen Fertigungszustand überprüft werden soll, und steuert, welche Tests ausgeführt werden. Wenn dieser Parameter nicht angegeben ist, wird standardmäßig "DeviceComplete" verwendet. Wenn sich der Herstellungszustand des Geräts von diesem Wert unterscheidet, schlägt die Überprüfung fehl. |
--images |
Gibt die Liste der Bild-IDs (GUIDs) an, die auf dem Gerät vorhanden sein müssen, damit die Überprüfung erfolgreich ist. Die Liste besteht aus den Bild-GUIDs, die durch Leerzeichen getrennt sind. Dieser Parameter wird standardmäßig für die leere Liste verwendet, falls nicht angegeben. Wenn sich die Liste der installierten Image-IDs auf dem Gerät von dieser Liste unterscheidet, schlägt die Überprüfung fehl. Durch Überprüfen von Bild-IDs (anstelle von Komponenten-IDs) wird sichergestellt, dass eine bestimmte Version einer Komponente vorhanden ist. |
--os |
Gibt eine Liste der Versionen des Azure Sphere-Betriebssystems an. Dieser Parameter wird standardmäßig für die leere Liste verwendet, wenn sie nicht angegeben wird. Wenn sich die auf dem Gerät vorhandene Betriebssystemversion nicht in dieser Liste befindet, schlägt diese Überprüfung fehl. |
--os_components_json_file |
Gibt den Pfad zur JSON-Datei an, in der die Betriebssystemkomponenten aufgeführt sind, die jede Version des Betriebssystems definieren. Für MT3620-basierte Geräte wird diese Datei mt3620an.json benannt. Verwenden Sie das download_os_list.py Tool, um die neueste Version herunterzuladen. |
--azsphere_path |
Gibt den Pfad zum hilfsprogramm azsphere.exe an. Wenn nicht angegeben, wird dieser Parameter standardmäßig auf den Standardinstallationsspeicherort für das Azure Sphere SDK unter Windows festgelegt. Verwenden Sie diesen Parameter nur, wenn das Azure Sphere SDK nicht am Standardspeicherort installiert ist. |
--help |
Zeigt die Hilfe für die Befehlszeile an. |
--verbose |
Stellt zusätzliche Ausgabedetails bereit. |
Das folgende Beispiel ist eine Beispielausführung des device_ready.py Tools mit den folgenden Argumenten:
--os 22.07--os_components_json_file mt3620an.json--expected_mfg_state Module1Complete
device_ready.py --os 22.07 --os_components_json_file mt3620an.json --expected_mfg_state Module1Complete
Checking device is in manufacturing state Module1Complete...
PASS: Device manufacturing state is Module1Complete
Checking capabilities...
PASS: No capabilities on device
Checking OS version...
PASS: OS '22.07' is an expected version
Checking installed images...
PASS: Installed images matches expected images
Checking wifi networks...
PASS: Device has no wifi networks configured
------------------
PASS
Festlegen des Herstellungszustands des Geräts
Sensible Herstellungsvorgänge, z.B. das Versetzen der Funkeinheit in den Testmodus und das Festlegen der e-fuse-Chips für die WLAN-Konfiguration, sollten für Endbenutzer von Geräten, die einen Azure Sphere-Chip enthalten, nicht zugänglich sein. Mit dem Herstellungszustand des Azure Sphere-Geräts wird der Zugriff auf diese sensiblen Vorgänge beschränkt.
Die drei Fertigungszustände sind wie folgt:
Blank: Der Leerzustand schränkt die Fertigungen auf einem Chip nicht ein. Chips im Leeren Zustand können in den RF-Testmodus eintreten und ihre E-Fuses können programmiert werden. Wenn Chips aus der Siliziumfabrik ausgeliefert werden, befinden sie sich im Zustand "Blank Manufacturing".
Module1Complete: Der Fertigungszustand "Module1Complete " ist so konzipiert, dass die Anpassungen der Benutzer an Funkkonfigurationseinstellungen wie maximale Übertragungsstärken und zulässigen Frequenzen beschränkt werden können. RF-Befehle können verwendet werden, bis Module1Complete festgelegt ist. Die Einschränkung des Endbenutzerzugriffs auf diese Einstellungen kann zur Einhaltung gesetzlicher Vorschriften im Zusammenhang mit Funkhardware erforderlich sein. Diese Einstellung betrifft hauptsächlich Hersteller, die Parameter für den Funkbetrieb testen und kalibrieren müssen.
Microsoft empfiehlt, diesen Herstellungszustand nach Abschluss der Funktests und der Funkkalibrierung festzulegen. Danach können keine Funkbefehle mehr verwendet werden. Der Status "Module1Complete " schützt das Gerät vor Änderungen, die den ordnungsgemäßen Betrieb des Funkgeräts und anderer drahtloser Geräte in der Nähe stören können.
DeviceComplete: Der Herstellungszustand "DeviceComplete " ermöglicht es Herstellern fertiger Produkte, Geräte zu sichern, die im Feld gegen Änderungen bereitgestellt werden. Sobald ein Gerät in den Zustand "DeviceComplete " versetzt wird, muss eine gerätespezifische Funktionsdatei verwendet werden, wenn Software geladen und Konfigurationsaufgaben ausgeführt werden. Mit der Fieldservicing-Funktion können Sie produktionssignierte Bilder querladen, aber nicht löschen. Die App-Entwicklungsfunktion ermöglicht sowohl das Querladen als auch das Löschen von Bildern.
Legen Sie DeviceComplete nicht für nicht fertige Geräte oder Module (WI-Fi-Module, Entwicklungsboards usw.) fest, die als Teil eines größeren Systems verwendet werden können. Dieser Zustand schränkt Fertigungsaktivitäten ein, z. B. Produktionslinientests, Softwareinstallation und Konfiguration. Viele CLI-Befehle sind nach dem Festlegen von DeviceComplete nicht verfügbar, sodass bestimmte Ready-to-Ship-Prüfungen ausgeführt werden müssen, bevor dieser Zustand festgelegt wird. Eingeschränkte Befehle können mithilfe einer Gerätefunktion wie der Fieldservicing-Funktion wieder aktiviert werden, aber nur für Geräte, die Sie beansprucht haben, und daher ist dies nicht für die Verwendung in einer Fabrikumgebung geeignet, da sie cloudkonnektivität erfordert.
In der folgenden Tabelle sind die Gerätefunktionen zusammengefasst, die für jeden Fertigungszustand vorhanden sind.
| Fertigungszustand | Gerätefunktionen |
|---|---|
| Leer | enableRfTestMode, fieldServicing und diejenigen, die entweder quergeladen oder mit einem Vorgang übergeben werden, wie in den Gerätefunktionen beschrieben. |
| Module1Complete | fieldServicing und diejenigen, die entweder quergeladen oder mit einem Vorgang übergeben werden, wie in den Gerätefunktionen beschrieben. |
| DeviceComplete | Nur diejenigen, die entweder quergeladen oder mit einem Vorgang übergeben werden, wie in den Gerätefunktionen beschrieben. |
Wenn die Fertigung abgeschlossen ist, verwenden Sie den Befehl "Azsphere Device Manufacturing-State Update", um den DeviceComplete-Zustand festzulegen:
azsphere device manufacturing-state update --state <desired-state> [--device <IP-address or connection-path>]
Hinweis
Wenn mehrere Geräte mit dem PC verbunden sind, schließen Sie den --device Parameter ein, um das Zielgerät anhand der IP-Adresse oder des Verbindungspfads zu identifizieren. Weitere Informationen finden Sie unter "Verbinden jedes Azure Sphere-Chips mit einem Fabrikboden-PC ".
Wichtig
Das Verschieben eines Chips in den DeviceComplete-Zustand ist ein dauerhafter Vorgang und kann nicht rückgängig gemacht werden. Sobald sich ein Chip im Zustand "DeviceComplete" befindet, kann er nicht in den RF-Testmodus wechseln. Seine E-Fuse-Einstellungen können nicht angepasst werden, und WLAN-Einstellungen, Betriebssystemupdates und installierte Anwendungen können nicht geändert werden, ohne das Gerät anzufordern und eine Gerätefunktion zu verwenden. Wenn Sie Funktionen auf einem einzelnen Chip erneut aktivieren müssen, die die Gerätefunktionen nicht wieder aktivieren, z. B. in einem Ausfallanalyseszenario, wenden Sie sich an Microsoft.