Tareas de la planta de producción
Importante
Esta es la documentación de Azure Sphere (heredado). Azure Sphere (heredado) se retira el 27 de septiembre de 2027 y los usuarios deben migrar a Azure Sphere (integrado) en este momento. Use el selector de versiones situado encima de la TOC para ver la documentación de Azure Sphere (integrado).
La fabricación de dispositivos conectados que incorporan hardware de Azure Sphere implica las siguientes tareas de fábrica para preparar los dispositivos para el envío:
- Conexión de cada chip de Azure Sphere a un equipo de fábrica
- Obtención de detalles del dispositivo y grabación de ellos para su uso posterior
- Actualización del sistema operativo De Azure Sphere, si es necesario
- Actualice el almacén de claves de confianza, si es necesario.
- Carga de software en el dispositivo
- Ejecución de pruebas funcionales para comprobar la operación correcta del producto
- Realización de pruebas y calibración de frecuencia de radio (RF)
- Comprobación de la comunicación wi-fi
- Configuración del dispositivo para Ethernet
- Finalización del dispositivo de Azure Sphere para el envío
Primero debe conectar el chip al equipo, obtener los detalles del dispositivo en segundo lugar y finalizar el dispositivo por última vez, pero puede realizar las otras tareas en cualquier orden que se adapte a su entorno de fabricación.
Importante
Debe realizar alguna preparación para asegurarse de que las tareas de la planta de fábrica se pueden completar sin retrasos. La preparación incluye la configuración del EQUIPO de planta de fábrica y cualquier otro equipo necesario e instalar las herramientas de software de PC necesarias. Todas las tareas que debe realizar para prepararse para un proceso de fabricación suave se describen en Preparación del proceso de fabricación.
Conexión de cada chip de Azure Sphere a un equipo de fábrica
Durante la fabricación, debe conectar cada chip de Azure Sphere a un equipo de fábrica. Si desea conectar simultáneamente varios dispositivos de Azure Sphere a un único equipo, consulte Equipos para tareas de fábrica en las tareas de preparación de fabricación.
La mayoría de las tareas de fábrica implican el comando azsphere device. Cuando tenga varios dispositivos conectados al equipo, debe especificar el dispositivo en el que se va a aplicar el comando azsphere device mediante la inclusión del --device parámetro establecido en la dirección IP del dispositivo o en la ruta de acceso de conexión del dispositivo. Se producirá un error en el comando si se omite el --device parámetro y se adjuntan varios dispositivos. Para obtener la dirección IP o la ruta de acceso de conexión, consulte Obtención de detalles del dispositivo.
Importante
La versión del SDK de Azure Sphere 23.05 y versiones posteriores admiten la comunicación con varios dispositivos conectados en Windows y Linux.
Obtención de los detalles del dispositivo
Debe registrar el identificador de dispositivo de cada chip de Azure Sphere que su empresa incorpore en productos fabricados. Necesitará el identificador de dispositivo para las tareas de configuración en la nube.
Si tiene varios dispositivos conectados al equipo de fábrica, también debe registrar la dirección IP o la ruta de acceso de conexión de los dispositivos conectados para su uso posterior en tareas de planta de fábrica. Como se explica en Conexión de cada chip de Azure Sphere, se requiere la dirección IP o la ruta de acceso de conexión para especificar el dispositivo de destino cuando haya varios dispositivos conectados.
Para obtener el identificador de dispositivo, la dirección IP y la ruta de acceso de conexión de los dispositivos conectados, use el comando azsphere device list-attached. Las descripciones siguientes proporcionan detalles esenciales sobre el identificador de dispositivo, la dirección IP y la ruta de acceso de conexión.
Id. de dispositivo: el fabricante de silicio crea el identificador de dispositivo, lo almacena en el chip y lo registra con Microsoft. Este registro de dispositivo garantiza que Microsoft tiene constancia de todos los chips de Azure Sphere y que solo se pueden usar chips legítimos en los dispositivos conectados.
Dirección IP: la dirección IP se asigna cuando se conecta una interfaz de dispositivo basada en FTDI al equipo; no indica que hay un dispositivo con capacidad de respuesta. La dirección IP persiste mientras la interfaz del dispositivo basada en FTDI está conectada al equipo, incluso si se conecta otro dispositivo de Azure Sphere a la interfaz. Sin embargo, después de reiniciar el equipo, la dirección IP puede cambiar. A la primera interfaz de dispositivo basada en FTDI que se va a conectar se le asigna la dirección 192.168.35.2. A cada dispositivo se le asigna una dirección IP, incluso si no responde, de modo que puede utilizar la dirección IP para identificar un dispositivo que requiere recuperación.
Ruta de acceso de conexión: la ruta de acceso de conexión es un identificador de ubicación FTDI que identifica la conexión USB. El identificador de ubicación persiste mientras la interfaz de dispositivo basada en FTDI está conectada al mismo puerto USB en el mismo concentrador USB y, a su vez, al mismo puerto del equipo. Por lo tanto, se conserva al reiniciar. Sin embargo, cualquier cambio en la conexión entre el equipo y el dispositivo puede provocar cambios en la ruta de conexión. Al igual que la dirección IP, no cambia incluso si un dispositivo de Azure Sphere diferente está conectado a la interfaz FTDI.
Actualización del sistema operativo de Azure Sphere
Todos los chips de Azure Sphere vienen con el sistema operativo correspondiente cuando el fabricante los envía. Según la versión del sistema operativo de Azure Sphere disponible en los chips del proveedor y según los requisitos de versión del sistema operativo de la aplicación, puede que tenga que actualizarlo durante la fabricación del dispositivo conectado. Puede actualizar el sistema operativo instalando imágenes de recuperación específicas, que ya deben estar presentes en el equipo. Consulte Preparación para una actualización del sistema operativo en las tareas de preparación de fabricación. Los ejemplos de fabricación incluyen un script de ejemplo que realiza la recuperación de varios dispositivos en paralelo.
Para actualizar el sistema operativo en el dispositivo de Azure Sphere, emita el comando azsphere device recover. Use el --images parámetro para instalar imágenes de recuperación específicas:
azsphere device recover --images <path-to-images> [--device <IP-address or connection-path>]
Nota:
Si hay varios dispositivos conectados al equipo, incluya el --device parámetro para identificar el dispositivo de destino por dirección IP o ruta de acceso de conexión. Consulte Conexión de cada chip de Azure Sphere a un equipo de fábrica para más información.
Actualización del almacén de claves de confianza
Como requisito previo para cargar software en el dispositivo, es posible que tenga que actualizar el almacén de claves de confianza en el dispositivo. Esto solo es necesario si el sistema operativo del dispositivo es anterior al software y solo si la clave de firma de imágenes de Azure Sphere usada por AS3 se actualizó entre el sistema operativo que se publica y el software con firma de producción. Para evitar este paso y reducir el tiempo de fabricación, considere la posibilidad de actualizar la versión del sistema operativo que usa durante la fabricación.
Puede determinar fácilmente si es necesario actualizar el almacén de claves de confianza intentando cargar el software según las instrucciones de la sección siguiente. Si la carga se realiza correctamente, no es necesario actualizar el almacén de claves de confianza. Si se produce un error en la carga con el mensaje que comienza con Internal device error: Image not trusted by device , el almacén de claves de confianza obsoleto es la causa.
Para actualizar el almacén de claves de confianza, debe haber adquirido el archivo de almacén de claves de confianza actualizado. A continuación, como parte de los scripts de fabricación, use el comando azsphere device sideload deploy para cargar el almacén de claves de confianza actualizado antes de cargar el software de la aplicación, reemplazando <path-to-trusted-keystore.bin> por la ruta de acceso al archivo de almacén de claves de confianza:
azsphere device sideload deploy --image-package <path-to-trusted-keystore.bin> [--device <IP-address or connection-path>]
Cargar software de dispositivo
Todo el software que cargue, independientemente de si se trata de una imagen de configuración de placa, una aplicación de prueba o una aplicación de producción, debe estar firmada por producción. Si carga una aplicación temporal para las pruebas, debe eliminarla una vez completada la prueba.
Todas las imágenes firmadas por producción que necesite durante el proceso de fábrica deben guardarse en su PC de fábrica antes de comenzar el proceso, como se describe en Obtener imágenes firmadas por producción en las tareas de preparación de fabricación.
Durante la fabricación, los dispositivos de Azure Sphere no requieren funcionalidad de dispositivo especial como, por ejemplo, la funcionalidad appDevelopment, que habilita la depuración. La adquisición de funcionalidades para dispositivos individuales reduce la seguridad de estos y requiere conexión a Internet lo cual, normalmente, no es deseable en la planta de producción.
Para cargar software en un dispositivo de fábrica o eliminar software temporal de un dispositivo una vez completada la prueba, use el comando azsphere device sideload como se indica a continuación:
Use azsphere device sideload deploy para cargar una imagen, reemplazando
<file-path>por el nombre y la ruta de acceso al archivo de imagen firmado por producción:azsphere device sideload deploy --image-package <file-path> [--device <IP-address or connection-path>]
Use azsphere device sideload delete para eliminar una imagen temporal, reemplazando
<component-id>por el identificador de componente de la imagen que se va a eliminar:azsphere device sideload delete --component-id <component-id> [--device <IP-address or connection-path>]
Nota:
Si hay varios dispositivos conectados al equipo, incluya el --device parámetro para identificar el dispositivo de destino por dirección IP o ruta de acceso de conexión. Consulte Conexión de cada chip de Azure Sphere a un equipo de fábrica para más información.
Ejecución de pruebas funcionales
Las pruebas funcionales son necesarias para comprobar que el producto funciona correctamente. Ejecute las aplicaciones desarrolladas para pruebas funcionales como parte de las tareas de preparación de fabricación. Consulte Desarrollo de aplicaciones para pruebas funcionales.
Si las pruebas funcionales requieren comunicación con el chip que se está probando, conecte los UART periféricos MT3620 (ISU0, ISU1, ISU2 o ISU3) a su PC de fábrica o a equipos de prueba externos a través de circuitos adecuados de su propio diseño.
Realización de pruebas y calibración de frecuencia de radio (RF)
Los chips de Azure Sphere pueden usar Wi-Fi para recibir actualizaciones de software y comunicarse con Internet. Si el producto usa Wi-Fi e incorpora un diseño de chip o un módulo que no está certificado por RF, debe realizar pruebas de RF y calibración para cada dispositivo. Los equipos y herramientas necesarios para esta tarea se describen en Equipo y software para pruebas de RF y calibración en las tareas de preparación de fabricación.
El paquete herramientas de RF incluye utilidades y una biblioteca de API de C para su uso durante las pruebas. Puede usar la biblioteca de API de C para programar la configuración de RF específica del producto en fusibles electrónicos. Por ejemplo, los fusibles electrónicos están programados para configurar la antena y la frecuencia, para ajustar los dispositivos para un rendimiento óptimo y para habilitar los canales Wi-Fi. El tema Herramientas de prueba de radiofrecuencia describe cómo usar las herramientas de radiofrecuencia.
Programas de fusibles electrónicos para habilitar canales Wi-Fi
El sistema operativo Azure Sphere selecciona canales Wi-Fi basados en el código de región que se programa en los fusibles electrónicos MT3620 en direcciones de desplazamiento 0x36 y 0x37. Para obtener más información sobre los fusibles electrónicos en el MT3620, consulte el documento Mt3620 E-fuse Content Guidelines Mediatek.
El código de región es un código ASCII de dos letras. El sistema operativo Azure Sphere usa la configuración de código de región en los fusibles electrónicos para buscar la región en la base de datos normativa inalámbrica linux y, a continuación, selecciona los canales permitidos para esa región. Si no se programa ningún código de región en los fusibles electrónicos, en cuyo caso los fusibles electrónicos permanecen establecidos en 0x00 0x00, o si los caracteres "00" están programados, el sistema operativo tiene como valor predeterminado un conjunto conservador de canales que se permiten generalmente en todas las regiones. Los canales permitidos para la región "00" se especifican en la base de datos normativa inalámbrica linux.
La configuración de código de región en los fusibles electrónicos no necesita coincidir con el país en el que se usará el dispositivo. Los fabricantes pueden elegir cualquier código de región que se asigne a un conjunto permitido de canales para la región de operación. A menudo, diferentes regiones y países adoptan regulaciones similares o idénticas, que pueden permitir que los códigos de región se usen indistintamente.
Ejemplo: Para indicar al sistema operativo azure Sphere que seleccione canales Wi-Fi para la región "DE" (Alemania), program 0x44=D y 0x45=E en los fusibles electrónicos en las direcciones 0x36 y 0x37. A continuación se muestran los canales permitidos para Alemania, extraídos de la base de datos inalámbrica de Linux. La mayoría de los países de la Unión Europea (UE) permiten el mismo conjunto de canales.
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)
Comprobación de la configuración de radiofrecuencia
Use RfSettingsTool para comprobar que las opciones de configuración de radio, como la potencia de transmisión de destino, el código de región y la dirección de Control de acceso multimedia Wi-Fi (MAC) se han establecido correctamente. La documentación de la herramienta de configuración de radiofrecuencia proporciona más información sobre su uso.
Comprobación de la comunicación wi-fi
Considere la posibilidad de conectarse a un punto de acceso Wi-Fi para comprobar que la aplicación del producto puede comunicarse a través de Wi-Fi. Asegúrese de que la conexión Wi-Fi no tenga acceso a Internet, ya que puede producirse una actualización inalámbrica si el chip se conecta a un punto de acceso habilitado para Internet.
Para conectar un dispositivo a un punto de acceso Wi-Fi, siga las instrucciones del inicio rápido (pestaña CLI). Si hay varios dispositivos conectados al equipo, debe incluir el --device parámetro en el comando azsphere device wifi show-status y el comando azsphere device wifi add. Para más información sobre el uso del comando azsphere device con varios dispositivos conectados, consulte Conexión de cada chip de Azure Sphere a un equipo de fábrica.
Después de las pruebas de Wi-Fi, debe quitar los puntos de acceso Wi-Fi utilizados para realizar pruebas desde el chip para que estos no sean visibles para los clientes. La recuperación del dispositivo quita todos los datos de configuración de Wi-Fi del chip.
Configuración del dispositivo para Ethernet
Un dispositivo de Azure Sphere puede comunicarse a través de Ethernet. El dispositivo requiere un adaptador Ethernet externo y una imagen de configuración de placa para la comunicación a través de Ethernet.
Para configurar un dispositivo de Azure Sphere para Ethernet, conecte un adaptador Ethernet al dispositivo de Azure Sphere, como se describe en Conexión de adaptadores Ethernet.
El sistema operativo Azure Sphere admite dos dispositivos Ethernet.
- ENC28J60 de Microchip. Se trata de un adaptador de 10Base-T (10 mbps). Se puede cablear con un indicador LED a media velocidad dúplex, o sin un indicador LED a velocidad dúplex completa. Los devkits verados están conectados para la operación de dúplex medio.
- Wiznet W5500. Se trata de un adaptador 100Base-TX (100mpbs). Admite una pila TCP/IP integrada y modos de paso a través de NIC, pero Azure Sphere solo admite el paso a través de NIC al usar W5500 para la conectividad a Internet. Debido a las limitaciones de ancho de banda del bus, es posible que el dispositivo MT3620 no pueda alcanzar la velocidad completa de 100 mbps.
La interfaz Ethernet se habilitará automáticamente una vez cargada la configuración de la placa, como se describe en Carga de software de dispositivo y se reinicia el dispositivo. Todas las interfaces usan las direcciones IP dinámicas de forma predeterminada.
Finalización del dispositivo de Azure Sphere
La finalización garantiza que el dispositivo de Azure Sphere se encuentra en un estado protegido y está listo para enviarse a los clientes. Debe finalizar el dispositivo antes de proceder a su envío. La finalización incluye:
Ejecución de comprobaciones finales previas al envío para asegurarse de que están instalados el software de sistema correcto y la aplicación de producción, y de que las herramientas de radiofrecuencia están deshabilitadas.
Establecimiento del estado de fábrica del dispositivo para bloquear las herramientas de configuración de RF y calibración y prevenir brechas de seguridad.
Ejecución de comprobaciones listas para enviar
Es importante ejecutar comprobaciones listas para enviar antes de enviar un producto que incluya un dispositivo de Azure Sphere. Se deben realizar comprobaciones diferentes para diferentes estados de fabricación. Las comprobaciones listas para enviar garantizan lo siguiente:
- El estado de fabricación del dispositivo se establece correctamente para esa fase de fabricación.
- El sistema operativo de Azure Sphere en el dispositivo es válido y la versión esperada. Esto solo se puede comprobar para los dispositivos que aún no están en estado DeviceComplete.
- Las imágenes proporcionadas por el usuario en el dispositivo coinciden con la lista de imágenes esperadas. Esto solo se puede comprobar para los dispositivos que aún no están en estado DeviceComplete.
- No hay redes Wi-Fi inesperadas configuradas en el dispositivo. Esto solo se puede comprobar para los dispositivos que aún no están en estado DeviceComplete.
- El dispositivo no contiene ningún certificado de funcionalidad especial. En el caso de los dispositivos basados en MT3620, esto solo se puede comprobar en los dispositivos que no están en estado En blanco.
Las distintas comprobaciones son necesarias en distintas fases de fabricación porque el estado de fabricación del dispositivo determina las funcionalidades del dispositivo.
Las comprobaciones que ejecute también dependerán de si está diseñando un módulo o un dispositivo conectado. Por ejemplo, como fabricante de módulos, puede dejar el chip en estado de fabricación en blanco para que el cliente del módulo pueda realizar pruebas y configuraciones de radio adicionales.
Uso de device_ready.py para realizar comprobaciones
El paquete De muestras de fabricación incluye una herramienta denominada device_ready.py, que realiza las comprobaciones anteriores, según corresponda para cada estado de fabricación. Debe ejecutarse para cada uno de los estados de fabricación relevantes para el dispositivo.
En la tabla siguiente se enumeran los parámetros que toma el script de device_ready.py:
| Parámetro | Descripción |
|---|---|
--expected_mfg_state |
Determina el estado de fabricación que se va a comprobar y controla qué pruebas se ejecutan. Si no se especifica este parámetro, el valor predeterminado es "DeviceComplete". Si el estado de fabricación del dispositivo difiere de este valor, se produce un error en la comprobación. |
--images |
Especifica la lista de identificadores de imagen (GUID) que deben estar presentes en el dispositivo para que la comprobación se realice correctamente. La lista consta de los GUID de imagen separados por espacios. Este parámetro tiene como valor predeterminado la lista vacía si no se especifica. Si la lista de identificadores de imagen instalados en el dispositivo difiere de esta lista, se produce un error en la comprobación. Al comprobar los identificadores de imagen (en lugar de los identificadores de componente), esta comprobación garantiza que existe una versión específica de un componente. |
--os |
Especifica una lista de versiones del sistema operativo de Azure Sphere. Este parámetro tiene como valor predeterminado la lista vacía si no se proporciona. Si la versión del sistema operativo presente en el dispositivo no está en esta lista, se producirá un error en esta comprobación. |
--os_components_json_file |
Especifica la ruta de acceso al archivo JSON que enumera los componentes del sistema operativo que definen cada versión del sistema operativo. Para los dispositivos basados en MT3620, este archivo se denomina mt3620an.json. Use la download_os_list.py herramienta para descargar la versión más reciente. |
--azsphere_path |
Especifica la ruta de acceso a la utilidad azsphere.exe. Si no se especifica, este parámetro tiene como valor predeterminado la ubicación de instalación predeterminada para el SDK de Azure Sphere en Windows. Use este parámetro solo si Azure Sphere SDK no está instalado en la ubicación predeterminada. |
--help |
Muestra la ayuda de la línea de comandos. |
--verbose |
Proporciona detalles de salida adicionales. |
El ejemplo siguiente es una ejecución de ejemplo de la device_ready.py herramienta con los argumentos siguientes:
--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
Establecimiento del estado de fábrica del dispositivo
Las operaciones de fabricación más delicadas, como la colocación del dispositivo de radio en modo de prueba o la configuración de los fusibles electrónicos de configuración de Wi-Fi, no deberían ser accesibles para los usuarios finales de los dispositivos que contienen un chip de Azure Sphere. El estado de fabricación del dispositivo de Azure Sphere restringe el acceso a estas operaciones confidenciales.
Los tres estados de fabricación son los siguientes:
Blank. El estado Blank no limita las operaciones de fabricación en un chip. Los chips en estado En blanco pueden entrar en modo de prueba RF y sus fusibles electrónicos se pueden programar. Cuando los chips se envían desde la fábrica de silicio, se encuentran en estado de fabricación en blanco .
Module1Complete. El estado de fabricación Module1Complete está diseñado para limitar los ajustes que los usuarios pueden realizar en las opciones de configuración de radio, como los niveles máximos de potencia de transmisión y las frecuencias permitidas. Los comandos RF se pueden usar hasta que se establezca Module1Complete . Es posible que sea necesario restringir el acceso del usuario final a esta configuración para satisfacer las directivas regulatorias sobre hardware de radio. Esta configuración afecta principalmente a los fabricantes que necesitan probar y calibrar parámetros operativos de radio.
Microsoft recomienda establecer este estado de fábrica después de que se hayan completado las pruebas de radio y la calibración; los comandos de RF no se pueden usar una vez establecido. El estado Module1Complete protege el dispositivo contra los cambios que pueden interrumpir el funcionamiento adecuado de la radio y otros dispositivos inalámbricos en las proximidades.
DeviceComplete. El estado de fabricación deviceComplete permite a los fabricantes de productos terminados proteger los dispositivos que se implementan en el campo frente a los cambios. Una vez que un dispositivo se coloca en el estado DeviceComplete , se debe usar un archivo de funcionalidad específico del dispositivo siempre que realice tareas de carga y configuración de software. La funcionalidad fieldservicing permite transferir localmente imágenes firmadas por producción, pero no eliminarlas. La funcionalidad appdevelopment permite transferir localmente y eliminar imágenes.
No establezca DeviceComplete para dispositivos o módulos sin terminar (módulos Wi-Fi, paneles de desarrollo, etc.) que se pueden usar como parte de un sistema más grande; este estado limita las actividades de fabricación, como pruebas de línea de producción, instalación de software y configuración. Muchos comandos de la CLI no están disponibles después de establecer DeviceComplete y, por tanto, se deben ejecutar determinadas comprobaciones listas para enviar antes de establecer este estado. Los comandos restringidos se pueden volver a habilitar mediante una funcionalidad de dispositivo, como la funcionalidad fieldservicing , pero solo para los dispositivos que ha reclamado y, por lo tanto, esto no es adecuado para su uso en un entorno de planta de fábrica, ya que requiere conectividad en la nube.
En la tabla siguiente se resumen las funcionalidades del dispositivo que están presentes para cada estado de fabricación.
| Estado de fabricación | Funcionalidades del dispositivo |
|---|---|
| En blanco | enableRfTestMode, fieldServicing y aquellos que se cargan localmente o se pasan con una operación, como se describe en Funcionalidades del dispositivo. |
| Module1Complete | fieldServicing y aquellos que se descargan localmente o se pasan con una operación, como se describe en Funcionalidades del dispositivo. |
| DeviceComplete | Solo aquellos que se cargan localmente o se pasan con una operación, como se describe en Funcionalidades del dispositivo. |
Una vez completada la fabricación, use el comando azsphere device manufacturing-state update para establecer el estado DeviceComplete:
azsphere device manufacturing-state update --state <desired-state> [--device <IP-address or connection-path>]
Nota:
Si hay varios dispositivos conectados al equipo, incluya el --device parámetro para identificar el dispositivo de destino por dirección IP o ruta de acceso de conexión. Consulte Conexión de cada chip de Azure Sphere a un equipo de fábrica para más información.
Importante
Mover un chip al estado DeviceComplete es una operación permanente y no se puede deshacer. Una vez que un chip está en estado DeviceComplete, no puede entrar en el modo de prueba rf; no se puede ajustar su configuración de fusible electrónico; y la configuración de Wi-Fi, las actualizaciones del sistema operativo y las aplicaciones instaladas no se pueden cambiar sin reclamar el dispositivo y usar una funcionalidad de dispositivo. Si necesita volver a habilitar funciones en un chip individual que las funcionalidades del dispositivo no vuelvan a habilitar, como en un escenario de análisis de errores, póngase en contacto con Microsoft.