Errores de solución de problemas de la  - Gratis RTOS
Solucione los problemas de configuración del dispositivoSolucione los errores de tiempo de esperaFunción de telefonía móvil y cargos AWSPolítica de generación de informes de calificación

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. Usa el resultado de la RTOS consola de IDT for Free para buscar el identificador de ejecución, el identificador del caso de prueba y el identificador del grupo de pruebas del caso de prueba que falló y, a continuación, abre el archivo de registro del caso de prueba denominado. 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 detallado IDT para el resultado de la RTOS consola de Free.

Le recomendamos que utilice el siguiente flujo de trabajo para solucionar problemas:

  1. Si ves el error»user/role no está autorizado a acceder a este recurso», asegúrese de configurar los permisos tal y como se especifica enCree y configure una AWS cuenta.

  2. Lea el resultado de la consola para buscar información, como la ejecución UUID y las tareas que se están ejecutando actualmente.

  3. 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.

  4. Consulte los archivos de registro de /results/execution-id/logs.

  5. Investigue alguna de las siguientes áreas de problemas:

    • Configuración del dispositivo, como los archivos JSON de configuración de la /configs/ carpeta.

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

    • En el FRQ caso de la versión 1.x.x, asegúrese de que haya disponible una versión limpia y clonada del código RTOS fuente gratuito. Los RTOS lanzamientos gratuitos se etiquetan según la versión gratuita. RTOS 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

Solucione los problemas de configuración del dispositivo

Cuando utilice IDT for FreeRTOS, debe disponer de 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?

Comience por leer el resultado de la consola para buscar información, como la ejecuciónUUID, a la que se hace referencia 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 for 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 la placa microcontroladora.

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:

  • AWS Región no válida: especifique una AWS región válida en el config.json archivo. Para obtener más información sobre las regiones de AWS , consulte Regiones y puntos de conexión.

  • AWS Credenciales no válidas: establezca AWS credenciales válidas en su máquina de prueba (mediante variables de entorno o el archivo de credenciales). Compruebe que el campo de autenticación se haya configurado correctamente. Para obtener más información, consulte Cree y configure una AWS cuenta.

203

CopySourceCodeError

No se puede copiar el código RTOS fuente gratuito al directorio especificado.

Compruebe los siguientes elementos:

  • Compruebe que se haya especificado una sourcePath válida en el archivo userdata.json.

  • Elimine la build carpeta del directorio de códigos RTOS fuente gratuitos, si existe. Para obtener más información, consulte Configurar ajustes de Build, Flash y Test.

  • Windows tiene un límite de caracteres para los nombres de las rutas de los archivos. Si introduce un nombre de ruta de archivo largo, se producirá un error.

204

BuildSourceError

No se puede compilar el código RTOS fuente gratuito.

Compruebe los siguientes elementos:

  • Compruebe que la información de buildTool del archivo userdata.json sea correcta.

  • Si utiliza cmake como herramienta de compilación, asegúrese de que se haya especificado {{enableTests}} en el comando buildTool. Para obtener más información, consulte Configurar ajustes de Build, Flash y Test.

  • Si, IDT por ejemploC:\Users\My Name\Desktop\, ha extraído gratuitamente RTOS una ruta de archivo del sistema que contiene espacios, es posible que necesite comillas adicionales en los comandos de compilación para asegurarse de que las rutas se analizan correctamente. Es posible que necesite lo mismo para los comandos flash.

205

FlashOrRunTestError

IDTFree RTOS no puede flashear ni ejecutar Free RTOS en suDUT.

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.

206

StartEchoServerError

IDTFree RTOS no puede iniciar el servidor Echo para las pruebas WiFi ni para 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.

Depure los errores de análisis del archivo de configuración

En ocasiones, un error tipográfico en una JSON configuración puede provocar errores de análisis. La mayoría de las veces, el problema se debe a que se omite un paréntesis, una coma o una cita en el archivo. JSON IDTfor Free RTOS realiza la JSON validación e imprime la 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 ayudarle a corregir el error, pero si aún tiene problemas para localizar el error, puede realizar la validación manualmente en su editor de textoIDE, como Atom o Sublime, o mediante una herramienta en línea comoJSONLint.

Los resultados de las pruebas de depuración analizan los errores

Al ejecutar un grupo de pruebas, por ejemplo FreeRTOS-Libraries-Integration-Tests, Full PKCS11 _Core FullTransportInterfaceTLS, Full _Onboard_, Full PKCS11 _Onboard_ECC, Full PKCS11 _RSA, Full PKCS11 PreProvisioned _ o OTACore, si es gratuitoECC, RTOS analiza los resultados de la prueba desde el IDT dispositivo de prueba con la conexión en serie. PKCS11 PreProvisioned RSA 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 RTOS de prueba de IDT for Free (que incluye todos los resultados IDT en serie que Free RTOS ha recibido durante la prueba) puede mostrar lo siguiente:


<unrelated device output>
TEST(Full_PKCS11_Capabilities, PKCS11_Capabilities)<unrelated device output>
<unrelated device output>
 PASS

En el ejemplo anterior, la salida del dispositivo no relacionada impide que IDT For Free RTOS detecte el resultado de la prueba, que es PASS.

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 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 sería que un IDT registro de casos de RTOS prueba gratuito mostrara 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

Depurar errores en la comprobación de integridad

Si utiliza la versión FRQ 1.x.x de Free, se aplican RTOS las siguientes comprobaciones de integridad.

Si ejecuta el grupo de reeRTOSIntegrity pruebas F y encuentra 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 ejecutas IDT el list-supported-products comando s, puedes encontrar qué rama etiquetada del freertos repositorio deberías usar.

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 una versión RTOS gratuita sin modificar los archivos ni la estructura de carpetas, asegúrate de que no se haya modificado ninguno de los archivos que figuran en las secciones minimal «exhaustive» y «» del checksums.json archivo. Para ejecutarlo con un archivo SDK configurado, compruebe que no se haya modificado ninguno de los archivos de la sección minimal «».

Si ejecuta IDT SDK y ha modificado algunos archivos de su freertos directorio, asegúrese de configurarlos correctamente SDK en su userdata archivo. De lo contrario, el comprobador de integridad verificará todos los archivos del directorio freertos.

Depure los errores de los grupos FullWiFi de prueba

Si utiliza la versión FRQ 1.x.x y encuentra errores en el grupo de FullWiFi prueba y la prueba «AFQP_WiFiConnectMultipleAP» falla, es posible que ambos puntos de acceso no estén en la misma subred que el equipo host que se está ejecutando. IDT Asegúrese de que ambos puntos de acceso estén en la misma subred que la computadora host en ejecución. IDT

Depure los errores de «falta un parámetro obligatorio»

Como se están añadiendo nuevas funciones de forma IDT gratuitaRTOS, es posible que se introduzcan 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. IDTfor Free RTOS valida los esquemas de los archivos de JSON configuración para asegurarse de que se ha utilizado la última versión compatible.

Depure los errores de tipo «la prueba no pudo iniciarse»

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.

Depure los errores «no se pueden encontrar los resultados de inicio de la prueba»

Es posible que veas errores al IDT intentar 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é IDT se está recibiendo.

  • Si utilizas la FRQ versión 1.x.x y el dispositivo que se está probando está conectado a través de una red lenta u otra interfaz, o no ves el indicador «--------- STARTING TESTS ---------» en el registro de un grupo de RTOS prueba gratuito junto con otros resultados de un grupo de RTOS prueba gratuito, puedes intentar aumentar el valor de tu configuración de datos de usuario. testStartDelayms Para obtener más información, consulte Configurar ajustes de Build, Flash y Test.

Depura el error «Fallo en la prueba: se esperaban __ resultados pero se detectaron ___»

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 RTOS pruebas gratuitas se ejecutan IDT antes de ver la salida 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.

Depure el error «________ no ha sido seleccionado 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 OTADataplaneMQTT pruebas y en el archivo de device.json configuración, ha elegido No o OTA OTADataPlaneProtocol como. HTTP El grupo de pruebas elegido para ejecutarse debe coincidir con sus selecciones de capacidad de device.json.

Depura un IDT tiempo de espera durante la supervisión de la salida del dispositivo

IDTpuede agotarse el tiempo de espera debido a varias razones. Si se agota el tiempo de espera durante la fase de monitorización de la salida del dispositivo de una prueba y puedes ver los resultados en el registro de casos de IDT prueba, significa que los resultados se han analizado incorrectamente. IDT 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, consulta la Guía de RTOS portabilidad gratuita para obtener más información sobre cómo configurar los UNITY registros.

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 un único fallo en un caso de TLS prueba. 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.

Depure un error de «no está autorizado a acceder al recurso»

Puede que veas el error»user/role no 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 AWS cuenta.

Depure los errores de las pruebas de red

Para las pruebas basadas en la red, IDT inicia un servidor echo que se vincula a un puerto no reservado de la máquina 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. 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

OTAerrores de actualización debido a la carga útil de la misma versión

Si los casos de OTA prueba fallan debido a que el dispositivo OTA tenía la misma versión después de haber realizado una, es posible que tu sistema de compilación (por ejemplo, cmake) no haya notado IDT los cambios en el código RTOS fuente gratuito y no haya creado un binario actualizado. Esto provoca OTA que se realicen con el mismo binario que se encuentra actualmente en el dispositivo y que la prueba falle. Para solucionar los errores de OTA actualización, empieza por asegurarte de que estás utilizando la última versión compatible de tu sistema de compilación.

OTAerror de prueba en caso de PresignedUrlExpired prueba

Un requisito previo de esta prueba es que el tiempo de OTA actualización sea superior a 60 segundos; de lo contrario, la prueba fallaría. 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.).

Depure los errores de interfaz y puerto del dispositivo

Esta sección contiene información sobre las interfaces de dispositivo que se IDT utilizan para conectarse a sus dispositivos.

Plataformas admitidas

IDTes 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 *

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 conecta un WRover dispositivo Espressif y los dos puertos que tiene asignados son /dev/ttyUSB0 y/dev/ttyUSB1, utilícelo /dev/ttyUSB1 en su archivo. device.json

En el caso de Windows, siga la misma lógica.

Lectura de datos de dispositivo

IDTfor Free RTOS utiliza herramientas flash y de creación de dispositivos individuales 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

Estos ajustes los gestiona IDT for FreeRTOS. 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:

  • GratisRTOS, no se puede compilar ni actualizar su 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 Build intenta ejecutarse en GUI modo incluso cuando se invoca sin cabeza.

Registro

IDTde forma gratuita, los RTOS registros se colocan en una sola ubicación. Desde el IDT directorio raíz, estos archivos están disponibles enresults/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 el resultado de la RTOS consola gratuita IDT para buscar el identificador de ejecución, el identificador del caso de prueba y el identificador del grupo de pruebas del caso de prueba que falló. 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 presiona CTRL+C mientras se ejecutaIDT, IDT se iniciará un proceso de limpieza. Parte de esa limpieza consiste en eliminar los recursos de Amazon S3 que se crearon como parte de las IDT pruebas. 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 presiona CTRL+C para detenerloIDT, 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.

Solucione los 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.

IDT v3.0.0 and later
./devicetester_linux run-suite --suite-id FRQ_1.0.1 --pool-id DevicePool1 --timeout-multiplier 2.5
IDT v1.7.0 and earlier
./devicetester_linux run-suite --suite-id FRQ_1 --pool-id DevicePool1 --timeout-multiplier 2.5

Función de telefonía móvil y cargos AWS

Cuando la Cellular función esté configurada Yes en su device.JSON archivo, FullSecureSockets utilizará EC2 instancias t.micro para ejecutar las pruebas, lo que puede suponer costes adicionales para su AWS cuenta. Para obtener más información, consulta los EC2precios de Amazon.

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 RTOS las versiones gratuitas 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.