Condividi tramite

Attività di produzione

  • Articolo

Importante

Questa è la documentazione di Azure Sphere (legacy). Azure Sphere (legacy) viene ritirato il 27 settembre 2027 e gli utenti devono eseguire la migrazione ad Azure Sphere (integrato) entro questo periodo. Usare il selettore di versione posizionato sopra il sommario per visualizzare la documentazione di Azure Sphere (integrata).

La produzione di dispositivi connessi che incorporano l'hardware di Azure Sphere comporta le attività seguenti per la preparazione dei dispositivi per la spedizione:

  • Connessione di ogni chip Azure Sphere a un PC di produzione
  • Ottenere i dettagli del dispositivo e registrarli per usarli in un secondo momento
  • Aggiornamento del sistema operativo Azure Sphere, se necessario
  • Aggiornare l'archivio chiavi attendibile, se necessario
  • Caricamento del software nel dispositivo
  • Esecuzione di test funzionali per verificare l'operazione corretta del prodotto
  • Esecuzione di test e calibrazione della radiofrequenza (RF)
  • Verifica della comunicazione Wi-Fi
  • Configurazione del dispositivo per Ethernet
  • Finalizzazione del dispositivo Azure Sphere per la spedizione

È necessario connettere il chip al PC per primo, ottenere i dettagli del dispositivo secondo e finalizzare l'ultimo dispositivo, ma è possibile eseguire le altre attività in qualsiasi ordine adatto all'ambiente di produzione.

Importante

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

Connettere ogni chip Azure Sphere a un PC di produzione

Durante la produzione, è necessario connettere ogni chip Azure Sphere a un PC di produzione. Per connettere simultaneamente più dispositivi Azure Sphere a un singolo PC, vedere Apparecchiature per le attività di produzione nelle attività di preparazione della produzione.

La maggior parte delle attività di produzione prevede il comando azsphere device. Quando al PC sono collegati più dispositivi, è necessario specificare il dispositivo in cui applicare il comando azsphere device 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 vengono collegati più dispositivi. Per ottenere l'indirizzo IP o il percorso di connessione, vedere Ottenere i dettagli del dispositivo.

Importante

La versione di Azure Sphere 23.05 SDK e le versioni successive supportano la comunicazione con più dispositivi collegati in Windows e Linux.

Ottenere i dettagli del dispositivo

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

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

Per ottenere l'ID dispositivo, l'indirizzo IP e il percorso di connessione dei dispositivi collegati, usare il comando azsphere device list-attached. Le descrizioni seguenti forniscono informazioni essenziali sull'ID dispositivo, l'indirizzo IP e il percorso di connessione.

  • ID dispositivo: il produttore del processore crea l'ID dispositivo, lo archivia nel chip e lo registra con Microsoft. La 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 un'interfaccia del dispositivo basata su FTDI è collegata al PC; non indica che è presente un dispositivo reattivo. L'indirizzo IP viene mantenuto finché l'interfaccia del dispositivo basata su FTDI è collegata al PC, anche se viene collegato un dispositivo Azure Sphere diverso. Dopo un riavvio del PC, tuttavia, l'indirizzo IP potrebbe cambiare. Alla prima interfaccia del dispositivo basata su FTDI da collegare viene assegnato l'indirizzo 192.168.35.2. A ogni dispositivo è assegnato un indirizzo IP, anche se non è reattivo, quindi è possibile usare tale indirizzo per identificare un dispositivo per cui è necessario un ripristino.

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

Aggiornare il sistema operativo Azure Sphere

Alla spedizione da parte del produttore, in ogni chip Azure Sphere viene caricato il sistema operativo Azure Sphere. A seconda della versione del sistema operativo Azure Sphere sui chip disponibili presso il proprio fornitore e a seconda dei requisiti di versione del sistema operativo dell'applicazione, potrebbe essere necessario aggiornare il sistema operativo Azure Sphere durante la produzione del dispositivo connesso. È possibile aggiornare il sistema operativo installando immagini di ripristino specifiche, che dovrebbero essere già presenti nel 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.

È possibile aggiornare il sistema operativo nel dispositivo Azure Sphere eseguendo il comando azsphere device recover. Usare il --images parametro per installare immagini di ripristino specifiche:

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

Nota

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

Aggiornare l'archivio chiavi attendibile

Come prerequisito per il caricamento del software nel dispositivo, potrebbe essere necessario aggiornare l'archivio chiavi 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 di Azure Sphere usata da AS3 è stata aggiornata tra il sistema operativo pubblicato e il software firmato dall'ambiente di produzione. Per evitare questo passaggio e ridurre il tempo di produzione, è consigliabile aggiornare la versione del sistema operativo in uso durante la produzione.

È possibile determinare facilmente se l'aggiornamento dell'archivio chiavi attendibile è necessario tentando di caricare il software in base alle istruzioni riportate nella sezione successiva. Se il caricamento ha esito positivo, non è necessario aggiornare l'archivio chiavi attendibile. Se il caricamento non riesce con il messaggio che inizia con Internal device error: Image not trusted by device , un archivio chiavi attendibile non aggiornato è la causa.

Per aggiornare l'archivio chiavi attendibile, è necessario avere acquisito il file dell'archivio chiavi attendibile aggiornato. Quindi, come parte degli script di produzione, usare il comando azsphere device sideload deploy per caricare l'archivio chiavi attendibile aggiornato prima del caricamento del software dell'applicazione, sostituendo <path-to-trusted-keystore.bin> con il percorso del file dell'archivio chiavi attendibile:

azsphere 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 dall'ambiente di produzione. Se si carica un'applicazione temporanea per il test, è necessario eliminarla al termine del test.

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

Interfaccia PC con strumenti

Durante la produzione, i dispositivi Azure Sphere non devono richiedere l'installazione di funzionalità di dispositivo speciali, ad esempio la funzionalità appdevelopment, che abilita il debug. L'acquisizione di funzionalità per i singoli dispositivi riduce la sicurezza dei dispositivi e richiede la connettività Internet, che è in genere indesiderata nel processo di produzione.

Per caricare il software in un dispositivo nella factory o per eliminare il software temporaneo da un dispositivo al termine del test, usare il comando azsphere device sideload come indicato di seguito:

Nota

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

Eseguire test funzionali

I test funzionali sono necessari per verificare che il prodotto funzioni correttamente. Eseguire le applicazioni sviluppate per i test funzionali come parte delle attività di preparazione della produzione. Vedere Sviluppare applicazioni per i test funzionali.

Se i test funzionali richiedono la comunicazione con il chip che viene testato, connettere gli UART periferici MT3620 (ISU0, ISU1, ISU2 o ISU3) al PC di produzione o alle apparecchiature di test esterne tramite circuiti adatti del proprio progetto.

Flusso del test funzionale

Eseguire test e calibrazione della radiofrequenza (RF)

I chip Azure Sphere possono usare il Wi-Fi per ricevere gli aggiornamenti software e comunicare con Internet. Se il prodotto usa wi-fi e incorpora una progettazione chip-down o un modulo non certificato RF, è necessario eseguire test RF e calibrazione per ogni dispositivo. Le attrezzature e gli strumenti necessari per questa attività sono descritti in Apparecchiature e software per i test RF e la calibrazione nelle attività di preparazione della produzione.

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

Programmi fusibili per abilitare i canali Wi-Fi

Il sistema operativo Azure Sphere seleziona i canali Wi-Fi in base al codice dell'area programmato nei fusibili e-fuse MT3620 negli indirizzi di offset 0x36 e 0x37. Per informazioni dettagliate sulle e-fuse su MT3620, vedere il documento MT3620 E-fuse Content Guidelines Mediatek.

Il codice di area è un codice ASCII a due lettere. Il sistema operativo Azure Sphere usa l'impostazione del codice dell'area nelle e-fuse per cercare l'area nel database normativo wireless Linux e quindi seleziona i canali consentiti per tale area. Se non viene programmato alcun codice di area nelle e-fuse, nel qual caso le e-fuse rimangono impostate su 0x00 0x00 o se i caratteri "00" sono programmati, il sistema operativo usa per impostazione predefinita un set conservativo di canali generalmente consentiti in tutte le aree. I canali consentiti per l'area "00" vengono specificati nel database normativo wireless Linux.

L'impostazione del codice dell'area nelle e-fuse non deve corrispondere al paese in cui verrà usato il dispositivo. I produttori possono scegliere qualsiasi codice di area mappato a un set consentito di canali per l'area operativa. Aree geografiche e paesi diversi spesso adottano normative simili o identiche, che possono consentire l'uso intercambiabile dei codici di area.

Esempio: per indicare al sistema operativo Azure Sphere di selezionare i canali Wi-Fi per l'area "DE" (Germania), programma 0x44=D e 0x45=E negli e-fuse in indirizzi 0x36 e 0x37. I canali consentiti per la Germania, estratti dal database normativo wireless Linux, sono illustrati 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 RF

Usare RfSettingsTool per verificare che le opzioni di configurazione radio, ad esempio l'alimentazione di trasmissione di destinazione, il codice di area e l'indirizzo MAC (Wi-Fi Media Controllo di accesso) siano stati impostati correttamente. La documentazione sullo strumento di impostazione RF fornisce altre informazioni sull'uso relativo.

Verificare la comunicazione Wi-Fi

Valutare la possibilità di connettersi a un punto di accesso Wi-Fi per verificare che l'applicazione del prodotto sia in grado di comunicare tramite Wi-Fi. Assicurarsi che la connessione Wi-Fi non abbia accesso a Internet, perché può verificarsi un aggiornamento over-the-air se il chip si connette a un punto di accesso abilitato per Internet.

Per connettere un dispositivo a un punto di accesso Wi-Fi, seguire le istruzioni nella scheda Avvio rapido (interfaccia della riga di comando). Se più dispositivi sono connessi al PC, è necessario includere il --device parametro nel comando azsphere device wifi show-status e il comando azsphere device wifi add. Per informazioni dettagliate sull'uso del comando azsphere device con più dispositivi collegati, vedere Connettere ogni chip Azure Sphere a un PC di produzione.

Dopo il test Wi-Fi, devi rimuovere tutti i punti di accesso Wi-Fi usati per il test dal chip in modo che 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, connettere una scheda Ethernet al dispositivo Azure Sphere, come descritto in Connessione di schede Ethernet.

Due dispositivi Ethernet sono supportati dal sistema operativo Azure Sphere.

  1. ENC28J60 di Microprocessore. Si tratta di una scheda 10Base-T (10 mbps). Può essere collegato con un indicatore LED a velocità half duplex o senza un indicatore LED a velocità full duplex. I devkit visualizzati sono cablati per l'operazione half-duplex.
  2. Wiznet W5500. Si tratta di un adattatore da 100Base-TX (100mpbs). Supporta una modalità pass-through TCP/IP integrata e pass-through della scheda di interfaccia di rete, ma Azure Sphere supporta solo il pass-through della scheda di interfaccia di rete quando si usa W5500 per la connettività Internet. A causa delle limitazioni della larghezza di banda del bus, la velocità massima di 100 mb 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 usano indirizzi IP dinamici per impostazione predefinita.

Finalizzare il dispositivo di Azure Sphere

La finalizzazione garantisce che il dispositivo di Azure Sphere sia in uno stato protetto e pronto per essere consegnato ai clienti. È necessario finalizzare il dispositivo prima della spedizione. La finalizzazione implica:

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

  • Impostazione dello stato di produzione del dispositivo in modo da bloccare gli strumenti di configurazione e calibrazione RF 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. È necessario eseguire controlli diversi per diversi stati di produzione. I controlli pronti per la spedizione assicurano quanto segue:

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

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

I controlli eseguiti dipendono anche dal fatto che si stia progettando un modulo o un dispositivo connesso. Ad esempio, come produttore di moduli, è possibile scegliere di lasciare il chip nello stato di produzione Vuoto in modo che il cliente del modulo possa eseguire test e configurazione radio aggiuntivi.

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 per ogni stato di produzione. Deve essere eseguita per ognuno degli stati di produzione rilevanti per il dispositivo.

Nella tabella seguente sono elencati i parametri accettati dallo script device_ready.py:

Parametro Descrizione
--expected_mfg_state Determina lo stato di produzione da controllare e controllare quali test vengono eseguiti. Se questo parametro non viene 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 affinché il controllo abbia esito positivo. L'elenco è costituito dai GUID dell'immagine separati da spazi. Questo parametro viene impostato per impostazione predefinita sull'elenco vuoto, se non specificato. Se l'elenco degli ID immagine installati nel dispositivo è diverso da questo elenco, il controllo ha esito negativo. Controllando gli ID immagine (anziché gli ID componente) questo controllo garantisce che sia presente una versione specifica di un componente.
--os Specifica un elenco di versioni del sistema operativo Azure Sphere. Questo parametro viene impostato per impostazione predefinita sull'elenco vuoto, se non specificato. Se la versione del sistema operativo presente nel dispositivo non è presente in questo elenco, questo controllo ha esito negativo.
--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 usa per impostazione predefinita il percorso di installazione predefinito per 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 dettagli di output aggiuntivi.

L'esempio seguente è un'esecuzione di esempio 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 del dispositivo

Le operazioni sensibili di produzione, come l'inserimento della radio in modalità test e l'impostazione di eFuse di configurazione Wi-Fi, non dovrebbero essere accessibili agli utenti finali dei dispositivi contenenti un chip Azure Sphere. Lo stato di produzione del dispositivo Azure Sphere limita l'accesso a tali operazioni sensibili.

I tre stati di produzione sono i seguenti:

  • Blank. Lo stato Vuoto 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 possono essere programmati. Quando i chip vengono spediti dalla fabbrica di siliconi, si trovano nello stato di produzione Vuoto .

  • Module1Complete. Lo stato di produzione Module1Complete è progettato per limitare le regolazioni che gli utenti possono apportare alle impostazioni di configurazione radio, ad esempio livelli massimi di potenza di trasmissione e frequenze consentite. I comandi RF possono essere usati fino a quando Non è impostato Module1Complete . La limitazione dell'accesso dell'utente finale a queste impostazioni può essere necessaria per soddisfare criteri normativi relativi all'hardware della radio. Questa impostazione influisce principalmente sui produttori che hanno la necessità di testare e calibrare i parametri operativi della radio.

    Microsoft consiglia di impostare questo stato di produzione dopo il completamento dei test e della calibrazione della radio; dopo averlo impostato, non è possibile usare i comandi RF. 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 nel campo rispetto alle modifiche. Quando un dispositivo viene inserito nello stato DeviceComplete , è necessario usare un file di funzionalità specifico del dispositivo ogni volta che si eseguono attività di caricamento e configurazione del software. La funzionalità fieldservicing consente di trasferire localmente immagini firmate dall'ambiente di produzione, ma non di eliminarle. La funzionalità appdevelopment consente sia il trasferimento locale che l'eliminazione di immagini.

    Non impostare DeviceComplete per dispositivi o moduli non finiti (moduli Wi-Fi, schede di sviluppo e così via) che possono essere usati come parte di un sistema più ampio. Questo stato limita le attività di produzione, ad esempio test line di produzione, installazione software e configurazione. Molti comandi dell'interfaccia della riga di comando non sono disponibili dopo l'impostazione di DeviceComplete e pertanto è necessario eseguire alcuni controlli pronti per la spedizione prima che questo stato sia impostato. I comandi con restrizioni possono essere riabilitato usando una funzionalità del dispositivo, ad esempio la funzionalità fieldservicing , ma solo per i dispositivi richiesti e pertanto non è appropriato per l'uso in un ambiente factory-floor perché richiede la connettività cloud.

La tabella seguente riepiloga le funzionalità del dispositivo presenti per ogni stato di produzione.

Stato di produzione Funzionalità del dispositivo
Spazio vuoto enableRfTestMode, fieldServicing e quelli sideload o passati con un'operazione, come descritto in Funzionalità del dispositivo.
Module1Complete fieldServicing e quelli sideload o passati con un'operazione, come descritto in Funzionalità del dispositivo.
DeviceComplete Solo quelle trasferite localmente o passate con un'operazione, come descritto in Funzionalità del dispositivo.

Al termine della produzione, usare il comando azsphere device manufacturing-state update per impostare lo stato DeviceComplete :

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

Nota

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

Importante

Lo spostamento di un chip nello stato DeviceComplete è un'operazione permanente e non può essere annullata. Una volta che un chip è nello stato DeviceComplete , non può entrare in modalità di test RF; le impostazioni di e-fuse non possono essere modificate e le impostazioni Wi-Fi, gli aggiornamenti del sistema operativo e le applicazioni installate non possono essere modificate senza richiedere il dispositivo e usare una funzionalità del dispositivo. Se è necessario riabilitare le funzioni in un singolo chip che le funzionalità del dispositivo non riabilitare, ad esempio in uno scenario di analisi degli errori, contattare Microsoft.