Attività di produzione

La produzione di dispositivi connessi che incorporano hardware Azure Sphere comporta le seguenti attività di produzione per preparare i dispositivi per la spedizione:

• Collegamento di ogni chip Azure Sphere a un PC di produzione
• Recupero dei dettagli del dispositivo e registrazione per un uso successivo
• Aggiornamento del sistema operativo Azure Sphere, se necessario
• Aggiornare il keystore attendibile, se necessario
• Caricamento del software nel dispositivo
• Esecuzione di test funzionali per verificare il corretto funzionamento del prodotto
• Esecuzione di test e calibrazione delle radiofrequenze (RF)
• Verifica della comunicazione Wi-Fi
• Configurazione del dispositivo per Ethernet
• Finalizzazione del dispositivo Azure Sphere per la spedizione

È necessario collegare prima il chip al PC, ottenere i dettagli del dispositivo secondo e finalizzare il dispositivo per ultimo, ma è possibile eseguire le altre attività in qualsiasi ordine che si adatta all'ambiente di produzione.

Importante

È consigliabile prepararsi per assicurarsi che le attività del reparto produzione possano essere completate senza ritardi. La preparazione include la configurazione del PC a piano di fabbrica e di qualsiasi altra attrezzatura necessaria e l'installazione degli strumenti software necessari per IL PC. Tutte le attività da eseguire per preparare un processo di produzione uniforme sono descritte in Preparazione del processo di produzione.

Collegare ogni chip Azure Sphere a un PC a livello di fabbrica

Durante la produzione, è necessario collegare ogni chip Azure Sphere a un PC a livello di fabbrica. Se si desidera connettere contemporaneamente più dispositivi Azure Sphere a un singolo PC, vedere Apparecchiature per le attività a livello di fabbrica nelle attività di preparazione della produzione.

La maggior parte delle attività di produzione-pavimento coinvolgono il comando dispositivo sfera az . Quando hai più dispositivi collegati al PC, devi specificare il dispositivo su cui applicare il comando del dispositivo sfera az includendo il --device parametro impostato sull'indirizzo IP del dispositivo o sul percorso di connessione del dispositivo. Il comando avrà esito negativo se il --device parametro viene omesso e sono collegati più dispositivi. Per ottenere l'indirizzo IP o il percorso di connessione, vedi Ottenere i dettagli del dispositivo.

Importante

Azure Sphere SDK supporta la comunicazione con più dispositivi collegati solo con Windows. Se usi Linux, è supportata la comunicazione con un solo dispositivo collegato. Tuttavia, è possibile utilizzare più macchine virtuali Linux (VM), ognuna con una singola porta USB mappata ad essa, per avere un singolo PC con più istanze Linux che comunicano con più dispositivi Azure Sphere contemporaneamente.

Ottieni i dettagli del dispositivo

È necessario registrare l'ID dispositivo di ogni chip Azure Sphere incorporato dall'azienda nei prodotti prodotti. Sarà necessario l'ID dispositivo per le attività di configurazione cloud.

Se si dispone di più dispositivi collegati al PC dell'azienda, è necessario registrare anche l'indirizzo IP o il percorso di connessione dei dispositivi collegati per usarli successivamente nelle attività di produzione. Come spiegato in Connetti ogni chip Azure Sphere, l'indirizzo IP o il percorso di connessione è necessario per specificare il dispositivo di destinazione quando sono presenti più dispositivi collegati.

Per ottenere l'ID del dispositivo, l'indirizzo IP e il percorso di connessione dei dispositivi collegati, usa il comando associato all'elenco di dispositivi az sphere . Le descrizioni seguenti forniscono dettagli essenziali sull'ID del dispositivo, l'indirizzo IP e il percorso di connessione.

• ID dispositivo: il produttore del processore crea l'ID del dispositivo, lo archivia nel chip e lo registra con Microsoft. Questa registrazione del dispositivo garantisce che Microsoft sia a conoscenza di tutti i chip azure sphere e che solo i chip legittimi possano essere usati nei dispositivi connessi.

• Indirizzo IP : l'indirizzo IP viene assegnato quando al PC è collegata un'interfaccia del dispositivo basata su FTDI; non indica che è presente un dispositivo reattivo. L'indirizzo IP persiste mentre l'interfaccia del dispositivo basata su FTDI è collegata al PC, anche se all'interfaccia è collegato un altro dispositivo Azure Sphere. Dopo il riavvio del PC, tuttavia, l'indirizzo IP potrebbe cambiare. All'indirizzo 192.168.35.2 viene assegnata la prima interfaccia di dispositivo basata su FTDI. A ogni dispositivo viene assegnato un indirizzo IP, anche se non risponde, in modo che tu possa usare l'indirizzo IP per identificare un dispositivo che richiede il ripristino.

• Percorso di connessione: il percorso di connessione è un ID posizione FTDI che identifica la connessione USB. L'ID posizione viene mantenuto mentre l'interfaccia del dispositivo basata su FTDI è collegata alla stessa porta USB sullo stesso hub USB e, a sua volta, alla stessa porta del PC. Pertanto, persiste durante il riavvio. Tuttavia, eventuali modifiche apportate al collegamento tra il PC e il dispositivo potrebbero comportare modifiche al percorso di connessione. Come l'indirizzo IP, non cambia anche se un altro dispositivo Azure Sphere è collegato all'interfaccia FTDI.

Aggiornare il sistema operativo Azure Sphere

Ogni chip Azure Sphere viene caricato con il sistema operativo Azure Sphere quando viene fornito dal produttore del processore. A seconda della versione del sistema operativo Azure Sphere sui chip disponibili nel fornitore e in base ai requisiti della versione del sistema operativo dell'applicazione, potrebbe essere necessario aggiornare il sistema operativo Azure Sphere durante la produzione del dispositivo connesso. Puoi aggiornare il sistema operativo installando immagini di ripristino specifiche, che dovrebbero già essere presenti nel tuo PC. Vedere Preparare un aggiornamento del sistema operativo nelle attività di preparazione della produzione. Gli esempi di produzione includono uno script di esempio che esegue il ripristino parallelo di più dispositivi.

Puoi aggiornare il sistema operativo nel dispositivo Azure Sphere rilasciando il comando di recupero del dispositivo az sphere . Usa il --images parametro per installare immagini di ripristino specifiche:

az sphere device recover --images <path-to-images> [--device <IP-address or connection-path>]

Nota

Se al PC sono connessi più dispositivi, includere il --device parametro per identificare il dispositivo di destinazione in base all'indirizzo IP o al percorso di connessione. Per informazioni dettagliate, vedi Collegare ogni chip Azure Sphere a un PC a livello di fabbrica .

Aggiornare l'archivio chiavi attendibile

Come prerequisito per caricare il software nel dispositivo, potrebbe essere necessario aggiornare il keystore attendibile nel dispositivo. Questa operazione è necessaria solo se il sistema operativo nel dispositivo è precedente al software e solo se la chiave di firma dell'immagine Azure Sphere usata da AS3 è stata aggiornata tra la pubblicazione del sistema operativo e la firma del software in produzione. Per evitare questo passaggio e ridurre i tempi di produzione, è consigliabile aggiornare la versione del sistema operativo in uso durante la produzione.

È possibile determinare facilmente se è necessario aggiornare il keystore attendibile provando a caricare il software in base alle istruzioni riportate nella sezione successiva. Se il caricamento riesce, non è necessario aggiornare il keystore attendibile. Se il caricamento non riesce con il messaggio che inizia con Internal device error: Image not trusted by device un keystore attendibile non aggiornato è la causa.

Per aggiornare il keystore attendibile, è necessario aver acquisito il file keystore attendibile aggiornato. Quindi, come parte degli script di produzione, usare il comando di distribuzione sideload del dispositivo az sphere per caricare il keystore attendibile aggiornato prima di caricare il software dell'applicazione, sostituendo <path-to-trusted-keystore.bin> con il percorso del file keystore attendibile:

az sphere device sideload deploy --image-package <path-to-trusted-keystore.bin> [--device <IP-address or connection-path>]

Caricare il software del dispositivo

Tutto il software caricato, indipendentemente dal fatto che si tratti di un'immagine di configurazione della scheda, di un'applicazione di test o di un'applicazione di produzione, deve essere firmato in produzione. Se si carica un'applicazione temporanea per il test, è necessario eliminarla al termine del test.

Tutte le immagini firmate in produzione necessarie durante il processo di produzione devono essere salvate nel PC del produttore prima di iniziare il processo, come descritto in Ottenere immagini firmate in produzione nelle attività di preparazione della produzione.

Durante la produzione, i dispositivi Azure Sphere non devono richiedere funzionalità speciali del dispositivo, come la funzionalità di sviluppo delle app, che consente il debug. L'acquisizione di capacità per singoli dispositivi riduce la sicurezza dei dispositivi e richiede la connettività Internet, che in genere non è consigliabile nel reparto produzione.

Per caricare software su un dispositivo in fabbrica o per eliminare il software temporaneo da un dispositivo al termine del test, utilizza il comando sideload del dispositivo az sphere come indicato di seguito:

• Usare il sideload del dispositivo az sphere per caricare un'immagine, sostituendo <file-path> con il nome e il percorso del file di immagine firmato di produzione:

  az sphere device sideload deploy --image-package <file-path> [--device <IP-address or connection-path>]
  

• Usa l'eliminazione sideload del dispositivo az sphere per eliminare un'immagine temporanea, sostituendo <component-id> con l'ID componente dell'immagine da eliminare:

  az sphere device sideload delete --component-id <component-id> [--device <IP-address or connection-path>]
  

Nota

Se al PC sono connessi più dispositivi, includere il --device parametro per identificare il dispositivo di destinazione in base all'indirizzo IP o al percorso di connessione. Per informazioni dettagliate, vedi Collegare ogni chip Azure Sphere a un PC a livello di fabbrica .

Eseguire test funzionali

Sono necessari test funzionali per verificare che il prodotto funzioni correttamente. Eseguire le applicazioni sviluppate per i test funzionali nell'ambito delle attività di preparazione della produzione. Vedere Sviluppare applicazioni per i test funzionali.

Se i test funzionali richiedono la comunicazione con il chip in fase di prova, collegare le periferiche UARTs (ISU0, ISU1, ISU2 o ISU3) alle apparecchiature di prova esterne o al PC a livello di fabbrica tramite circuiti appropriati di propria progettazione.

Eseguire test e calibrazione delle radiofrequenze (RF)

I chip Azure Sphere possono usare Wi-Fi per ricevere aggiornamenti software e comunicare con Internet. Se il prodotto utilizza Wi-Fi e incorpora un design chip-down o un modulo non certificato per le radiofrequenze, è necessario eseguire test rf e calibrazione per ogni dispositivo. Le apparecchiature e gli strumenti necessari per questa attività sono descritti in Apparecchiature e software per test RF e calibrazione nelle attività di preparazione della produzione.

Il pacchetto RF Tools include utilità e una libreria di API C da utilizzare durante i test. Puoi utilizzare la libreria di API C per programmare impostazioni RF specifiche del prodotto nei fusibili e-fuse. Ad esempio, i fusibili elettronici sono programmati per configurare l'antenna e la frequenza, ottimizzare i dispositivi per ottenere prestazioni ottimali e abilitare Wi-Fi canali. L'argomento Strumenti di test RF descrive come usare gli strumenti RF.

Programmare gli e-fuse per abilitare Wi-Fi canali

Il sistema operativo Azure Sphere seleziona Wi-Fi canali in base al codice regionale programmato nelle fusibili e-fuse MT3620 a indirizzi offset 0x36 e 0x37. Per informazioni dettagliate sui fusibili e-fuse su MT3620, vedi il documento Mediatek sulle linee guida per la fusione elettronica MT3620 .

Il codice dell'area geografica è un codice ASCII di due lettere. Il sistema operativo Azure Sphere utilizza l'impostazione del codice area negli e-fuse per cercare l'area geografica nel database di normative wireless Linux e quindi seleziona i canali consentiti per tale area geografica. Se nei fusibili e-fuse non viene programmato alcun codice regionale, nel qual caso i fusibili e-fuse rimangono impostati su 0x00 0x00 o se i caratteri "00" sono programmati, il sistema operativo imposta per impostazione predefinita un set conservativo di canali generalmente consentiti in tutte le aree geografiche. I canali consentiti per l'area geografica "00" sono specificati nel database delle normative wireless linux.

L'impostazione del codice dell'area geografica nei fusibili e-fuse non deve corrispondere al paese in cui verrà utilizzato il dispositivo. I produttori possono scegliere qualsiasi codice area geografica associato a un set di canali consentiti per l'area geografica di funzionamento. Aree geografiche e paesi diversi spesso adottano normative simili o identiche, che possono consentire l'uso intercambiabile dei codici regionali.

Esempio: Per indicare al sistema operativo Azure Sphere di selezionare Wi-Fi canali per l'area geografica "DE" (Germania), programmare 0x44=D e 0x45=E negli e-fuse agli indirizzi 0x36 e 0x37. I canali consentiti per la Germania, estratti dal database di normative wireless Linux, sono mostrati di seguito. La maggior parte dei paesi dell'Unione Europea (UE) consente lo stesso set di canali.

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)

Verificare la configurazione delle richieste di offerta

Usare lo RfSettingsTool per verificare che le opzioni di configurazione radio, ad esempio l'alimentazione di trasmissione di destinazione, il codice dell'area geografica e l'indirizzo Wi-Fi Media Controllo di accesso (MAC) siano state impostate correttamente. La documentazione dello strumento impostazioni RF fornisce ulteriori informazioni sull'uso di questo strumento.

Verifica Wi-Fi comunicazione

È consigliabile connettersi a un punto di accesso Wi-Fi per verificare che l'applicazione di prodotto sia in grado di comunicare tramite Wi-Fi. Assicurati che la connessione Wi-Fi non disponga di accesso a Internet, perché potrebbe verificarsi un aggiornamento via etere se il chip si connette a un punto di accesso abilitato per Internet.

Per connettere un dispositivo a un punto di accesso Wi-Fi, segui le istruzioni nella Guida introduttiva (scheda CLI). Se più dispositivi sono connessi al PC, è necessario includere il --device parametro nel dispositivo az sphere wifi show-status comando e il comando di aggiunta wifi dispositivo az sphere . Per informazioni dettagliate sull'uso del comando del dispositivo az sphere con più dispositivi collegati, vedi Collegare ogni chip Azure Sphere a un PC a livello di fabbrica.

Dopo Wi-Fi test, è consigliabile rimuovere dal chip tutti i punti di accesso Wi-Fi utilizzati per il test, in modo che questi non siano visibili ai clienti. Il ripristino del dispositivo rimuove tutti i dati di configurazione Wi-Fi dal chip.

Configurare il dispositivo per Ethernet

Un dispositivo Azure Sphere può comunicare tramite Ethernet. Il dispositivo richiede una scheda Ethernet esterna e un'immagine di configurazione della scheda per la comunicazione tramite Ethernet.

Per configurare un dispositivo Azure Sphere per Ethernet, connetti una scheda Ethernet al dispositivo Azure Sphere, come descritto in Schede Ethernet in connessione.

Due dispositivi Ethernet sono supportati dal sistema operativo Azure Sphere.

1. Microchip ENC28J60. Si tratta di un adattatore da 10Base-T (10 mbps). Può essere cablata con un indicatore LED alla velocità half-duplex o senza indicatore LED a velocità full-duplex. I devkit seeed sono cablati per l'operazione half-duplex.
2. Wiznet W5500. Questo è un adattatore 100Base-TX (100mpbs). Supporta uno stack TCP/IP integrato e le modalità pass-through NIC, ma Azure Sphere supporta solo il pass-through NIC quando si usa W5500 per la connettività Internet. A causa di limitazioni della larghezza di banda dell'autobus, la velocità massima di 100 mbps potrebbe non essere raggiungibile dal dispositivo MT3620.

L'interfaccia Ethernet verrà abilitata automaticamente dopo il caricamento della configurazione della scheda, come descritto in Caricare il software del dispositivo e il dispositivo viene riavviato. Tutte le interfacce utilizzano indirizzi IP dinamici per impostazione predefinita.

Finalizzare il dispositivo Azure Sphere

La finalizzazione assicura che il dispositivo Azure Sphere si trova in uno stato protetto ed è pronto per essere spedito ai clienti. Devi finalizzare il dispositivo prima di spediscirlo. La finalizzazione comporta:

• Esecuzione di controlli pronti per la spedizione per assicurarsi che vengano installati il software di sistema corretto e l'applicazione di produzione e che gli strumenti RF siano disabilitati.

• Impostazione dello stato di produzione del dispositivo per bloccare la configurazione delle radiofrequenza e gli strumenti di calibrazione e prevenire violazioni della sicurezza.

Eseguire controlli pronti per la spedizione

È importante eseguire controlli pronti per la spedizione prima di spedire un prodotto che include un dispositivo Azure Sphere. Controlli diversi devono essere eseguiti per diversi stati di produzione. I controlli pronti per la spedizione assicurano quanto segue:

• Lo stato di produzione del dispositivo è impostato correttamente per quella fase di produzione.
• Il sistema operativo Azure Sphere nel dispositivo è valido e la versione prevista. Questa operazione può essere controllata solo per i dispositivi non ancora in stato DeviceComplete.
• Le immagini fornite dall'utente nel dispositivo corrispondono all'elenco delle immagini previste. Questa operazione può essere controllata solo per i dispositivi non ancora in stato DeviceComplete.
• Nel dispositivo non sono configurate reti Wi-Fi impreviste. Questa operazione può essere controllata solo per i dispositivi non ancora in stato DeviceComplete.
• Il dispositivo non contiene certificati di funzionalità speciali. Per i dispositivi basati su MT3620, questo può essere controllato solo su dispositivi non nello stato Vuoto.

Nelle diverse fasi di produzione sono necessari controlli diversi perché lo stato di produzione del dispositivo determina le funzionalità del dispositivo.

I controlli eseguiti dipendono anche dalla progettazione di un modulo o di un dispositivo connesso. Ad esempio, come produttore di un modulo si potrebbe scegliere di lasciare il chip nello stato di produzione vuoto in modo che il cliente del modulo possa eseguire ulteriori test radio e configurazione.

Usare device_ready.py per eseguire i controlli

Il pacchetto Manufacturing Samples include uno strumento denominato device_ready.py, che esegue i controlli precedenti, in base alle esigenze di ogni stato di produzione. Dovrebbe essere eseguito per ogni stato di produzione rilevante per il tuo dispositivo.

Nella tabella seguente sono elencati i parametri che vengono eseguita dallo script device_ready.py:

Parametro	Descrizione
--expected_mfg_state	Determina lo stato di produzione da controllare e controlla quali test vengono eseguiti. Se questo parametro non è specificato, per impostazione predefinita è "DeviceComplete". Se lo stato di produzione del dispositivo è diverso da questo valore, il controllo non riesce.
--images	Specifica l'elenco di ID immagine (GUID) che devono essere presenti nel dispositivo per l'esito positivo del controllo. L'elenco è costituito dai GUID delle immagini separati da spazi. Questo parametro viene omesso per impostazione predefinita nell'elenco vuoto, se non è specificato. Se l'elenco degli ID immagine installati nel dispositivo è diverso da questo elenco, il controllo non riesce. Controllando gli ID immagine (anziché gli ID componente), questo controllo garantisce la presenza di una versione specifica di un componente.
--os	Specifica un elenco di versioni del sistema operativo Azure Sphere. Se non specificato, questo parametro viene vuoti per impostazione predefinita. Se la versione del sistema operativo presente nel dispositivo non è presente nell'elenco, il controllo non riesce.
--os_components_json_file	Specifica il percorso del file JSON che elenca i componenti del sistema operativo che definiscono ogni versione del sistema operativo. Per i dispositivi basati su MT3620, questo file è denominato mt3620an.json. Usare lo download_os_list.py strumento per scaricare la versione più recente.
--azsphere_path	Specifica il percorso dell'utilità azsphere.exe. Se non è specificato, questo parametro viene attivata per impostazione predefinita per la posizione di installazione di Azure Sphere SDK in Windows. Usare questo parametro solo se Azure Sphere SDK non è installato nella posizione predefinita.
--help	Mostra la Guida della riga di comando.
--verbose	Fornisce ulteriori dettagli di output.

L'esempio seguente è un esempio di esecuzione dello device_ready.py strumento con gli argomenti seguenti:

• --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

Impostare lo stato di produzione dei dispositivi

Operazioni di produzione sensibili, ad esempio l'inserimento della radio in modalità di test e l'impostazione Wi-Fi fusibili elettronici di configurazione non devono essere accessibili agli utenti finali di dispositivi che contengono un chip Azure Sphere. Lo stato di produzione del dispositivo Azure Sphere limita l'accesso a queste operazioni sensibili.

I tre stati di produzione sono i seguenti:

• Vuoto. Lo stato Blank non limita le operazioni di produzione su un chip. I chip nello stato Vuoto possono entrare in modalità di test RF e i loro fusibili e-fuse possono essere programmati. Quando i chip vengono spediti dalla fabbrica di processori, si trovano nello stato di produzione Vuoto .

• Module1Complete. Lo stato di produzione di Module1Complete è progettato per limitare le regolazioni che gli utenti possono apportare alle impostazioni di configurazione radio, ad esempio i livelli di potenza di trasmissione massimi e le frequenze consentite. I comandi RF possono essere usati finché non viene impostato Module1Complete . Può essere necessario limitare l'accesso degli utenti finali a queste impostazioni per soddisfare i criteri normativi relativi all'hardware radio. Questa impostazione interessa principalmente i produttori che devono testare e calibrare i parametri operativi della radio.

  Microsoft consiglia di impostare questo stato di produzione dopo aver completato i test radio e la calibrazione; I comandi RF non possono essere usati dopo l'impostazione. Lo stato Module1Complete protegge il dispositivo dalle modifiche che potrebbero interrompere il corretto funzionamento della radio e di altri dispositivi wireless nelle vicinanze.

• DeviceComplete. Lo stato di produzione DeviceComplete consente ai produttori di prodotti finiti di proteggere i dispositivi distribuiti sul campo contro le modifiche. Una volta che un dispositivo viene posizionato nello stato DeviceComplete , un file di funzionalità specifico del dispositivo deve essere utilizzato ogni volta che si eseguono attività di caricamento e configurazione del software. La funzionalità fieldservicing consente di sideload immagini firmate di produzione, ma non eliminarle. La capacità di appsviluppo consente sia il sideload e l'eliminazione di immagini.

  Non impostare DeviceComplete per dispositivi o moduli incompleti (moduli Wi-Fi, schede di sviluppo e così via) che possono essere utilizzati come parte di un sistema più grande; questo stato limita le attività di produzione, ad esempio i test della linea di produzione, l'installazione del software e la configurazione. Molti comandi CLI non sono disponibili dopo l'impostazione di DeviceComplete e pertanto è necessario eseguire alcuni controlli pronti per la spedizione prima di impostare questo stato. I comandi con restrizioni possono essere riattivata utilizzando una funzionalità del dispositivo come la funzionalità fieldservicing , ma solo per i dispositivi che hai rivendicato e pertanto non è appropriato per l'uso in un ambiente di produzione in quanto richiede la connettività cloud.

La tabella seguente riepiloga le funzionalità dei dispositivi presenti per ogni stato di produzione.

Stato di produzione	Funzionalità del dispositivo
Vuoto	enableRfTestMode, fieldServicing e quelli che vengono sideload o passati con un'operazione, come descritto in Funzionalità dispositivo.
Module1Complete	fieldServicing e quelli che vengono sideload o passati con un'operazione, come descritto in Funzionalità dispositivo.
Completamento dispositivo	Solo quelli che vengono caricati in sideload o passati con un'operazione, come descritto in Funzionalità del dispositivo.

Al termine della produzione, utilizza il comando di aggiornamento dello stato di produzione del dispositivo az sphere per impostare lo stato DeviceComplete :

az sphere device manufacturing-state update --state <desired-state> [--device <IP-address or connection-path>]

Nota

Se al PC sono connessi più dispositivi, includere il --device parametro per identificare il dispositivo di destinazione in base all'indirizzo IP o al percorso di connessione. Per informazioni dettagliate, vedi Collegare ogni chip Azure Sphere a un PC a livello di fabbrica .

Importante

Lo spostamento di un chip allo stato DeviceComplete è un'operazione permanente e non può essere annullata. Una volta che un chip è in stato DeviceComplete , non può entrare in modalità di test RF; le impostazioni del fusibili elettronico non possono essere regolate; e Wi-Fi le impostazioni, gli aggiornamenti del sistema operativo e le applicazioni installate non possono essere modificati senza richiedere il dispositivo e utilizzare una funzionalità del dispositivo. Se devi abilitare nuovamente le funzioni su un singolo chip che le funzionalità del dispositivo non rieseguire, ad esempio in uno scenario di analisi degli errori, contatta Microsoft.