Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés. # Errores de solución de problemas de la  Cada ejecución del conjunto de pruebas tiene un ID de ejecución único que se utiliza para crear una carpeta llamada `results/execution-id` en el directorio `results`. Los registros de grupos de pruebas individuales se encuentran en el directorio `results/execution-id/logs`. Utilice la salida de la consola de IDT para FreeRTOS para encontrar el ID de ejecución, el del caso de prueba y el del grupo de pruebas que tiene errores y, a continuación, abra el archivo de registro de ese caso de prueba llamado `results/execution-id/logs/test_group_id__test_case_id.log`. La información que incluye este archivo es la siguiente: + Salida completa de los comandos Build y Flash. + Salida de la ejecución de la prueba. + Más información sobre la salida de la consola de IDT para FreeRTOS. Le recomendamos que utilice el siguiente flujo de trabajo para solucionar problemas: 1. Si aparece el error «no *user/role* está autorizado a acceder a este recurso», asegúrese de configurar los permisos tal y como se especifica en. [Cree y configure una cuenta AWS](dev-tester-prereqs.md#config-aws-account) 1. Lea la salida de la consola para obtener información, como el UUID de ejecución y las tareas que se están ejecutando actualmente. 1. Examine el archivo `FRQ_Report.xml` para ver la lista de errores de cada prueba. Este directorio contiene los registros de ejecución de cada grupo de pruebas. 1. Consulte los archivos de registro de `/results/execution-id/logs`. 1. Investigue alguna de las siguientes áreas de problemas: + Configuración del dispositivo, como archivos de configuración JSON en la carpeta `/configs/`. + Interfaz del dispositivo. Compruebe los registros para determinar qué interfaz produce el error. + Herramientas de dispositivos. Asegúrese de que las cadenas de herramientas de compilación y actualización del dispositivo estén instaladas y configuradas correctamente. + Para FRQ 1.x.x, asegúrese de que haya disponible una versión limpia y clonada del código fuente de FreeRTOS. Las versiones de FreeRTOS se etiquetan según la versión de FreeRTOS. Para clonar una versión específica del código, utilice los comandos siguientes: ``` git clone --branch version-number https://github.com/aws/amazon-freertos.git cd amazon-freertos git submodule update --checkout --init --recursive ``` ## Solución de problemas de configuración del dispositivo Al utilizar IDT para FreeRTOS, debe tener implementados los archivos de configuración correctos antes de ejecutar el binario. Si obtiene errores de análisis y de configuración, el primer paso debe ser localizar y utilizar una plantilla de configuración adecuada para su entorno. Estas plantillas se encuentran en el directorio `IDT_ROOT/configs`. Si continúa teniendo problemas, consulte el siguiente proceso de depuración. ### ¿Dónde buscar? Para empezar, lea la salida de la consola para obtener información, como el UUID de ejecución, que se denomina `execution-id` en esta documentación. A continuación, examine el archivo `FRQ_Report.xml` del directorio `/results/execution-id`. Este archivo contiene todos los casos de prueba ejecutados y los fragmentos de error de cada error. Para obtener todos los registros de ejecución, busque el archivo `/results/execution-id/logs/test_group_id__test_case_id.log` de cada caso de prueba. ### Códigos de error de IDT En la siguiente tabla se explican los códigos de error generados por IDT para FreeRTOS: | Código de error | Nombre del código de error | Causa posible | Resolución de problemas | | --- | --- | --- | --- | | 201 | InvalidInputError | Los campos de `device.json`, `config.json` o `userdata.json` faltan o tienen un formato incorrecto. | Asegúrese de que no falten los campos obligatorios y de que tengan el formato obligatorio en los archivos de la lista. Para obtener más información, consulte [Primera prueba de su placa de microcontrolador](qual-steps.md). | | 202 | ValidationError | Los campos de `device.json`, `config.json` o `userdata.json` contienen valores no válidos. | Compruebe el mensaje de error en la parte derecha del código de error del informe: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/freertos/latest/userguide/dt-afr-troubleshooting.html) | | 203 | CopySourceCodeError | No se puede copiar el código fuente de FreeRTOS en el directorio especificado. | Compruebe los siguientes elementos: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/freertos/latest/userguide/dt-afr-troubleshooting.html) | | 204 | BuildSourceError | No se puede compilar el código fuente de FreeRTOS. | Compruebe los siguientes elementos: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/freertos/latest/userguide/dt-afr-troubleshooting.html) | | 205 | FlashOrRunTestError | IDT para FreeRTOS no puede instalar ni ejecutar FreeRTOS en su DUT. | Compruebe que la información de `flashTool` del archivo `userdata.json` sea correcta. Para obtener más información, consulte [Configurar ajustes de Build, Flash y Test](cfg-dt-ud.md). | | 206 | StartEchoServerError | IDT FreeRTOS no puede iniciar el servidor echo para las pruebas ni para WiFi las pruebas de sockets seguros. | Compruebe que los puertos que están configurados en `echoServerConfiguration` del archivo `userdata.json` no estén en uso o bloqueados por la configuración de la red o del firewall. | ### Depuración de errores de análisis del archivo de configuración Ocasionalmente, un error tipográfico en una configuración de JSON puede dar lugar a errores de análisis. En la mayoría de los casos, el problema es resultado de omitir un paréntesis, una coma o unas comillas en el archivo JSON. IDT para FreeRTOS realiza la validación de JSON e imprime información de depuración. Imprime la línea en la que se produjo el error, el número de línea y el número de la columna del error de sintaxis. Esta información debería ser suficiente para ayudarte a corregir el error, pero si sigues teniendo problemas para localizar el error, puedes realizar la validación manualmente en tu IDE, en un editor de texto como Atom o Sublime, o a través de una herramienta online como esta. JSONLint ### Depuración de errores de análisis de los resultados de las pruebas Al ejecutar un grupo de pruebas desde **FullTransportInterfaceTLS [ FreeRTOS-Libraries-Integration-Tests](https://github.com/FreeRTOS/FreeRTOS-Libraries-Integration-Tests), Full PKCS11 \$1Core, Full \$1Onboard\$1ECC, Full PKCS11 \$1Onboard\$1RSA, Full \$1 PKCS11 \$1ECC, Full \$1 PKCS11 \$1RSA o **OTACore**IDT for PKCS11 PreProvisioned FreeRTOS analiza los PreProvisioned resultados** de las pruebas del dispositivo de prueba con la conexión en serie. A veces, las salidas en serie adicionales del dispositivo pueden interferir con el análisis de los resultados de las pruebas. En el caso mencionado anteriormente, se emiten extraños motivos de fallo en un caso de prueba, como cadenas que se originan en salidas de dispositivos no relacionados. El archivo de registro de casos de prueba de IDT para FreeRTOS (que incluye todas las salidas en serie que IDT para FreeRTOS ha recibido durante la prueba) puede mostrar lo siguiente: ``` TEST(Full_PKCS11_Capabilities, PKCS11_Capabilities) PASS ``` En el ejemplo anterior, la salida del dispositivo no relacionado impide que IDT para FreeRTOS detecte el resultado de la prueba, que es **APROBADO**. Compruebe lo siguiente para garantizar que las pruebas sean óptimas. + Asegúrese de que las macros de registro utilizadas en el dispositivo sean seguras para subprocesos. Consulte [Implementación de las macros de registro de la biblioteca](https://docs.aws.amazon.com/freertos/latest/portingguide/afr-library-logging-macros.html) para obtener más información. + Asegúrese de que haya un mínimo de salidas en la conexión en serie durante las pruebas. Las salidas de otros dispositivos pueden ser un problema incluso si las macros de registro son seguras para subprocesos, ya que los resultados de las pruebas se generarán en llamadas independientes durante las pruebas. Lo ideal es que un registro de casos de prueba de IDT para FreeRTOS muestre un resultado de prueba ininterrumpido como el siguiente: ``` ---------STARTING TESTS--------- TEST(Full_OTA_PAL, otaPal_CloseFile_ValidSignature) PASS TEST(Full_OTA_PAL, otaPal_CloseFile_InvalidSignatureBlockWritten) PASS ----------------------- 2 Tests 0 Failures 0 Ignored ``` ### Depuración de errores de comprobación de integridad Si utiliza la versión FRQ 1.x.x de FreeRTOS, se aplican las siguientes comprobaciones de integridad. Cuando ejecute el grupo de RTOSIntegrity prueba gratuito y encuentre errores, asegúrese primero de no haber modificado ninguno de los archivos del `freertos` directorio. Si no lo ha hecho y sigue teniendo problemas, asegúrese de que está utilizando la rama correcta. Si ha ejecutado el comando `list-supported-products` de IDT, podrá encontrar qué rama etiquetada del repositorio `freertos` debería estar usando. Si ha clonado la rama etiquetada correcta del repositorio `freertos` y sigue teniendo problemas, asegúrese de haber ejecutado también el comando `submodule update`. El flujo de trabajo de clonación del repositorio `freertos` es el siguiente. ``` git clone --branch version-number https://github.com/aws/amazon-freertos.git cd amazon-freertos git submodule update --checkout —init —recursive ``` La lista de archivos que busca el comprobador de integridad se encuentra en el archivo `checksums.json` de su directorio `freertos`. Para calificar un puerto de FreeRTOS sin modificar los archivos ni la estructura de carpetas, asegúrese de que no se haya modificado ninguno de los archivos que figuran en las secciones “`exhaustive`” y “`minimal`” del archivo `checksums.json`. Para ejecutarlo con un SDK configurado, compruebe que no se haya modificado ninguno de los archivos de la sección “`minimal`”. Si ha ejecutado IDT con un SDK y ha modificado algunos archivos del directorio `freertos`, asegúrese de configurar correctamente el SDK en el archivo `userdata`. De lo contrario, el comprobador de integridad verificará todos los archivos del directorio `freertos`. ### Depure los errores del grupo FullWiFi de prueba Si utiliza FRQ 1.x.x y encuentra errores en el grupo de prueba y la FullWiFi prueba «`AFQP_WiFiConnectMultipleAP`» falla, puede deberse a que ambos puntos de acceso no están en la misma subred que el equipo host que ejecuta IDT. Asegúrese de que ambos puntos de acceso estén en la misma subred que el equipo host que ejecuta IDT. ### Depuración de error “required parameter missing” Dado que se están añadiendo nuevas características a IDT para FreeRTOS, es posible que se hayan introducido cambios en los archivos de configuración. Utilizar un archivo de configuración antiguo podría romper la configuración. Si esto ocurre, en el archivo `test_group_id__test_case_id.log` del directorio `results/execution-id/logs` se muestran explícitamente todos los parámetros que faltan. IDT para FreeRTOS también valida los esquemas del archivo de configuración JSON para asegurarse de que se ha utilizado la versión más reciente compatible. ### Depuración de errores “test could not start” Es posible que vea errores que apuntan a fallos durante el inicio de las pruebas. Dado que hay varias causas posibles, asegúrese de comprobar que las siguientes áreas son correctas: + Asegúrese de que el nombre del grupo que ha incluido en el comando de ejecución realmente existe. A esto se hace referencia directamente desde el archivo `device.json`. + Asegúrese de que el dispositivo o dispositivos del grupo tienen parámetros de configuración correctos. ### Depuración de errores que indican “unable to find start of test results” Es posible que vea errores cuando IDT intente analizar los resultados generados por el dispositivo que se está probando. Dado que hay varias causas posibles, asegúrese de comprobar que las siguientes áreas son correctas: + Asegúrese de que el dispositivo que se está probando tenga una conexión estable con su máquina host. Puede consultar el archivo de registro para ver si hay una prueba que muestre estos errores para ver qué recibe IDT. + Si utiliza FRQ 1.x.x y el dispositivo que se está probando está conectado a través de una red lenta u otra interfaz, o no ve el indicador “---------STARTING TESTS---------” en el registro de un grupo de pruebas de FreeRTOS junto con las salidas de otros grupos de pruebas de FreeRTOS, puede intentar aumentar el valor de `testStartDelayms` en la configuración de userdata. Para obtener más información, consulte [Configurar ajustes de Build, Flash y Test](cfg-dt-ud.md). ### Depuración del error “Test failure:expected \$1\$1 results but saw \$1\$1\$1\$1\$1\$1” Es posible que vea errores que apuntan a fallos durante las pruebas. La prueba espera una cantidad determinada de resultados y no se ven durante la prueba. Algunas pruebas de FreeRTOS se ejecutan antes de que IDT vea el resultado del dispositivo. Si aparece este error, puede intentar aumentar el valor de `testStartDelayms` en la configuración de *userdata*. Para obtener más información, consulte [Configurar ajustes de Build, Flash y Test](lts-cfg-dt-ud.md). ### Depure el error «\$1\$1\$1\$1\$1\$1\$1\$1 no se seleccionó debido a restricciones» ConditionalTests Esto significa que está realizando una prueba en un grupo de dispositivos que no es compatible con la prueba. Esto puede ocurrir con las pruebas E2E OTA. Por ejemplo, al ejecutar el grupo de pruebas `OTADataplaneMQTT` y en el archivo de configuración `device.json`, ha elegido OTA como **No** o `OTADataPlaneProtocol` como **HTTP**. El grupo de pruebas elegido para ejecutarse debe coincidir con sus selecciones de capacidad de `device.json`. ### Depuración de un tiempo de espera de IDT durante la supervisión de la salida del dispositivo Se puede agotar el tiempo de espera de IDT debido a varios motivos. Si se agota el tiempo de espera durante la fase de monitorización de la salida del dispositivo de una prueba y puede ver los resultados en el registro de casos de las pruebas de IDT, significa que IDT los analizó incorrectamente. Una de las razones podrían ser los mensajes de registro intercalados en medio de los resultados de las pruebas. Si este es el caso, consulte la [Guía de portabilidad de FreeRTOS](https://docs.aws.amazon.com/freertos/latest/portingguide/afr-porting-ota.html) para obtener más detalles sobre cómo se deben configurar los registros de UNITY. Otro motivo por el que se agota el tiempo de espera durante la monitorización de la salida del dispositivo podría ser que el dispositivo se reinicie tras fallar una sola prueba de TLS. A continuación, el dispositivo ejecuta la imagen instalada y provoca un bucle infinito que se ve en los registros. Si esto ocurre, asegúrate de que el dispositivo no se reinicie después de un error en la prueba. ### Error que indica “not authorized to access resource” Es posible que veas el error «no *user/role* está autorizado a acceder a este recurso» en la salida del terminal o en el `test_manager.log` archivo que aparece debajo`/results/execution-id/logs`. Para resolver este problema, asocie la política administrada `AWS IoTDeviceTesterForFreeRTOSFullAccess` al usuario de prueba. Para obtener más información, consulte [Cree y configure una cuenta AWS](dev-tester-prereqs.md#config-aws-account). ### Depuración de errores de prueba de red En las pruebas basada en red, IDT inicia un servidor de eco que se vincula a un puerto no reservado en el equipo host. Si se producen errores debido a que se han agotado los tiempos de espera o a que las conexiones no están disponibles en las pruebas WiFi o en las pruebas de sockets seguros, asegúrese de que la red esté configurada para permitir el tráfico a los puertos configurados en el rango de 1024 a 49151. Las pruebas de sockets seguros utiliza los puertos 33333 y 33334 de forma predeterminada. Las WiFi pruebas utilizan el puerto 33335 de forma predeterminada. Si estos tres puertos están en uso o bloqueados por el firewall o la red, puede elegir puertos diferentes para las pruebas en userdata.json. Para obtener más información, consulte [Configurar ajustes de Build, Flash y Test](cfg-dt-ud.md). Puede utilizar los siguientes comandos para comprobar si un puerto específico está en uso: + Windows: `netsh advfirewall firewall show rule name=all | grep port` + Linux: `sudo netstat -pan | grep port` + macOS: `netstat -nat | grep port` ### Errores de actualización de OTA producidos por una carga útil de la misma versión Si los casos de prueba OTA fallan porque la misma versión está en el dispositivo después de haber realizado una operación OTA, puede deberse a que su sistema de compilación (por ejemplo, cmake) no reconoció los cambios de IDT en el código fuente de FreeRTOS y no creó un binario actualizado. Esto hace que la actualización OTA se realice con el mismo binario que está actualmente en el dispositivo y que la prueba produzca un error. Para solucionar errores de actualización OTA, comience por asegurarse de que está utilizando la última versión compatible de su sistema de compilación. ### Fallo de prueba de OTA en caso de prueba de `PresignedUrlExpired` Un requisito previo de esta prueba es que el tiempo de actualización OTA sea superior a 60 segundos; de lo contrario, la prueba producirá un error. Si esto ocurre, encontrará el siguiente mensaje de error en el registro: "Test takes less than 60 seconds (url expired time) to finish. Please reach out to us" (La prueba tarda menos de 60 segundos (tiempo de vencimiento de la url) en finalizar. Póngase en contacto con nosotros.). ### Depuración de errores de puerto e interfaz del dispositivo Esta sección contiene información acerca de las interfaces de dispositivo que IDT utiliza para conectarse a sus dispositivos. #### Plataformas admitidas IDT es compatible con Linux, macOS y Windows. Las tres plataformas tienen diferentes esquemas de nomenclatura para dispositivos de serie que se asocian a ellas: + Linux: `/dev/tty*` + macOS: `/dev/tty.*` o `/dev/cu.*` + Windows: COM\$1 Para comprobar el puerto del dispositivo: + En Linux/macOS, abra un terminal y ejecute `ls /dev/tty*`. + En macOS, abra un terminal y ejecute `ls /dev/tty.*` o `ls /dev/cu.*`. + En el caso de Windows, abra el Administrador de dispositivos y expanda el grupo de dispositivos de serie. Para verificar qué dispositivo está conectado a un puerto: + En Linux, asegúrese de que el paquete `udev` está instalado y, a continuación, ejecute `udevadm info –name=PORT`. Esta utilidad imprime información del controlador de dispositivo que le ayuda a verificar que está utilizando el puerto correcto. + En macOS, abra Launchpad y busque **System Information**. + En el caso de Windows, abra el Administrador de dispositivos y expanda el grupo de dispositivos de serie. #### Interfaces de dispositivos Cada dispositivo integrado es diferente, lo que significa que pueden tener uno o más puertos de serie. Es frecuente que los dispositivos tengan dos puertos cuando se conectan a un equipo. + Un puerto de datos para actualizar el dispositivo. + Un puerto de lectura para leer la salida. Debe establecer el puerto de lectura correcto en el archivo `device.json`. De lo contrario, podría no ser posible leer la salida del dispositivo. En el caso de varios puertos, asegúrese de utilizar el puerto de lectura del dispositivo en el archivo `device.json`. Por ejemplo, si conectas un WRover dispositivo Espressif y los dos puertos que tiene asignados son `/dev/ttyUSB0` y`/dev/ttyUSB1`, `/dev/ttyUSB1` utilízalo en tu archivo. `device.json` En el caso de Windows, siga la misma lógica. #### Lectura de datos de dispositivo IDT para FreeRTOS utiliza herramientas individuales de compilación e instalación de dispositivos para especificar la configuración de los puertos. Si va a probar el dispositivo y no obtiene salida, pruebe los valores predeterminados siguientes: + Velocidad en baudios: 115 200 + Bits de datos: 8 + Paridad: ninguna + Bits de parada: 1 + Control del flujo: ninguno IDT para FreeRTOS administra esta configuración. No tiene que definirla. Sin embargo, puede utilizar el mismo método para leer manualmente la salida del dispositivo. En Linux o macOS, puede hacerlo con el comando `screen`. En Windows, puede usar un programa como. TeraTerm `Screen: screen /dev/cu.usbserial 115200` `TeraTerm: Use the above-provided settings to set the fields explicitly in the GUI.` ### Problemas de la cadena de herramientas de desarrollo En esta sección se explican los problemas que pueden ocurrir con la cadena de herramientas. #### Code Composer Studio en Ubuntu Las versiones más recientes de Ubuntu (17.10 y 18.04) tienen una versión del paquete `glibc` que no es compatible con las versiones de Code Composer Studio 7.*x*. Se recomienda instalar la versión de Code Composer Studio 8.2 o posterior. Los síntomas de incompatibilidad podrían incluir: + FreeRTOS no puede compilarse ni instalarse en el dispositivo. + El instalador de Code Composer Studio puede bloquearse. + No se muestra la salida de registro en la consola durante el proceso de compilación o actualización. + El comando de compilación intenta lanzarse en modo GUI incluso cuando se invoca como sin encabezado. ### Registro Los registros de IDT para FreeRTOS se colocan en una única ubicación. En el directorio IDT raíz, estos archivos están disponibles en `results/execution-id/`: + `FRQ_Report.xml` + `awsiotdevicetester_report.xml` + `logs/test_group_id__test_case_id.log` `FRQ_Report.xml` y `logs/test_group_id__test_case_id.log` son los registros más importantes que debe examinar. `FRQ_Report.xml` contiene información sobre qué casos de prueba registraron errores con un mensaje específico. Puede utilizar `logs/test_group_id__test_case_id.log` para investigar más a fondo el problema y tener más contexto. #### Errores de la consola Cuando AWS IoT Device Tester se ejecuta, los errores se notifican a la consola con breves mensajes. Busque en `results/execution-id/logs/test_group_id__test_case_id.log` para obtener más información sobre el error. #### Errores de registro Cada ejecución del conjunto de pruebas tiene un ID único que se utiliza para crear una carpeta llamada `results/execution-id`. Los registros de casos de prueba individuales se encuentran en el directorio `results/execution-id/logs`. Utilice la salida de la consola de IDT para FreeRTOS para encontrar el ID de ejecución, el ID del caso de prueba y el ID del grupo de pruebas que tiene errores. A continuación, utilice esta información para buscar y abrir el archivo de registro correspondiente al caso de prueba denominado. `results/execution-id/logs/test_group_id__test_case_id.log` La información de este archivo incluye el resultado completo de los comandos build y flash, el resultado de la ejecución de la prueba y el resultado de la AWS IoT Device Tester consola más detallado. #### Problemas con los buckets de S3 Si pulsa CTRL\$1C al ejecutar IDT, IDT iniciará un proceso de limpieza. Parte de esa limpieza consiste en eliminar los recursos de Amazon S3 que se crearon como parte de las pruebas de IDT. Si la limpieza no puede finalizar, es posible que se produzca un problema por el hecho de que se hayan creado demasiados buckets de Amazon S3. Esto significa que la próxima vez que ejecute IDT, las pruebas comenzarán a fallar. Si pulsa CTRL\$1C para detener IDT, debe dejar que finalice el proceso de limpieza para evitar este problema. También puede eliminar los buckets de Amazon S3 de su cuenta que se crearon manualmente. ## Resolución de problemas de errores de tiempo de espera Si ve errores de tiempo de espera mientras ejecuta un conjunto de pruebas, aumente el tiempo de espera especificando un factor multiplicador de tiempo de espera. Este factor se aplica al valor de tiempo de espera predeterminado. Cualquier valor configurado para esta marca debe ser superior o igual a 1,0. Para utilizar el multiplicador de tiempo de espera, utilice la marca `--timeout-multiplier` al ejecutar el conjunto de pruebas. **Example** ``` ./devicetester_linux run-suite --suite-id FRQ_1.0.1 --pool-id DevicePool1 --timeout-multiplier 2.5 ``` ``` ./devicetester_linux run-suite --suite-id FRQ_1 --pool-id DevicePool1 --timeout-multiplier 2.5 ``` ## Función móvil y cargos AWS Cuando la `Cellular` función esté configurada `Yes` en su `device.JSON` archivo, FullSecureSockets utilizará instancias EC2 de t.micro para ejecutar las pruebas, lo que puede suponer costes adicionales para su cuenta. AWS Para obtener más información, consulte [Precios de Amazon EC2](https://aws.amazon.com/ec2/pricing/). ## Política de generación de informes de calificación Los informes de calificación solo los generan las versiones AWS IoT Device Tester (IDT) que admiten las versiones de FreeRTOS publicadas en los últimos dos años. Si tiene alguna pregunta acerca de la política de compatibilidad, póngase en contacto con [AWS Support](https://aws.amazon.com/contact-us/).