As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Solucionar erros da 

Cada execução do conjunto de testes tem um ID de execução exclusivo que é usado para criar uma pasta chamada results/execution-id no diretório results. Os logs individuais do grupo de testes estão no diretório results/execution-id/logs. Use a saída do RTOS console IDT for Free para encontrar o ID de execução, o ID do caso de teste e o ID do grupo de teste do caso de teste que falhou e, em seguida, abra o arquivo de log desse caso de teste chamadoresults/execution-id/logs/test_group_id__test_case_id.log. As informações desse arquivo incluem:

Recomendamos o seguinte fluxo de trabalho para solucionar problemas:

Solucionar problemas de configuração do dispositivo

Ao usar o IDT for FreeRTOS, você deve instalar os arquivos de configuração corretos antes de executar o binário. Se você estiver recebendo erros de análise e configuração, o primeiro passo deve ser localizar e usar um modelo de configuração apropriado para seu ambiente. Esses modelos estão localizados no diretório IDT_ROOT/configs.

Se você ainda estiver com problemas, consulte o processo de depuração a seguir.

Onde eu procuro?

Comece lendo a saída do console para encontrar informações, como a execuçãoUUID, que é referenciada como execution-id nesta documentação.

Depois, examine o arquivo FRQ_Report.xml no diretório /results/execution-id. Este arquivo contém todos os casos de teste que foram executados e os trechos com erros para cada falha. Para obter todos os logs de execução, procure o arquivo para cada caso de teste /results/execution-id/logs/test_group_id__test_case_id.log.

Códigos de erro da IDT

A tabela a seguir explica os códigos de erro gerados pelo IDT for FreeRTOS:

Depurar erros de análise do arquivo de configuração

Ocasionalmente, um erro de digitação em uma JSON configuração pode levar a erros de análise. Na maioria das vezes, o problema é resultado da omissão de um colchete, vírgula ou citação do seu arquivo. JSON IDTfor Free RTOS executa a JSON validação e imprime informações de depuração. Ele imprime a linha em que ocorreu o erro, o número da linha e o número da coluna do erro de sintaxe. Essas informações devem ser suficientes para ajudá-lo a corrigir o erro, mas se você ainda tiver problemas para localizar o erro, poderá realizar a validação manualmente em seu editor de textoIDE, como Atom ou Sublime, ou por meio de uma ferramenta on-line como. JSONLint

Erros de análise de resultados de testes de depuração

Ao executar um grupo de teste de FreeRTOS-Libraries-Integration-Tests, como Full PKCS11 _Core FullTransportInterfaceTLS, Full _Onboard_, Full PKCS11 _Onboard_ECC, Full PKCS11 _ _RSA, Full PKCS11 _ PreProvisioned _ ouECC, IDT for Free OTACore, RTOS analisa os RSA resultados do teste do dispositivo de teste com a conexão serial. PKCS11 PreProvisioned Às vezes, saídas seriais extras no dispositivo podem interferir na análise dos resultados do teste.

No caso mencionado acima, motivos estranhos de falha em casos de teste, como cadeias de caracteres provenientes de saídas de dispositivos não relacionados, são gerados. O arquivo de registro do caso de RTOS teste IDT for Free (que inclui toda a saída IDT serial que o Free RTOS recebeu durante o teste) pode mostrar o seguinte:

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

No exemplo acima, a saída não relacionada do dispositivo impede que o IDT For Free detecte o resultado RTOS do teste, que é. PASS

Verifique o seguinte para garantir o teste ideal.

Idealmente, um IDT registro RTOS de casos de teste gratuito mostraria uma saída ininterrupta dos resultados do teste, como abaixo:

---------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 falhas na verificação de integridade

Se estiver usando a versão FRQ 1.x.x do Free, RTOS as seguintes verificações de integridade se aplicam.

Ao executar o grupo de reeRTOSIntegrity teste F e encontrar falhas, primeiro certifique-se de não ter modificado nenhum dos arquivos do freertos diretório. Se não fez isso e ainda está tendo problemas, verifique se está usando a ramificação correta. Se você executar IDT o list-supported-products comando, poderá descobrir qual ramificação marcada do freertos repositório você deve usar.

Se clonou a ramificação marcada correta do repositório freertos e ainda tiver problemas, verifique se também executou o comando submodule update. O fluxo de trabalho de clonagem para o repositório freertos é o seguinte.

git clone --branch version-number https://github.com/aws/amazon-freertos.git
cd amazon-freertos
git submodule update --checkout —init —recursive

A lista de arquivos que o verificador de integridade procura está no arquivo checksums.json em seu diretório freertos. Para qualificar uma RTOS porta livre sem nenhuma modificação nos arquivos e na estrutura de pastas, certifique-se de que nenhum dos arquivos listados nas seções 'exhaustive' e 'minimal' do checksums.json arquivo tenha sido modificado. Para executar com um SDK configurado, verifique se nenhum dos arquivos na seção minimal '' foi modificado.

Se você executa IDT com um SDK e modificou alguns arquivos em seu freertos diretório, certifique-se de configurá-lo corretamente SDK em seu userdata arquivo. Caso contrário, o verificador de integridade verificará todos os arquivos no diretório freertos.

Depurar falhas FullWiFi do grupo de teste

Se você estiver usando FRQ 1.x.x e encontrar falhas no grupo de FullWiFi teste, e o teste "AFQP_WiFiConnectMultipleAP" falhar, isso pode ser porque os dois pontos de acesso não estão na mesma sub-rede do computador host em execução. IDT Verifique se os dois pontos de acesso estão na mesma sub-rede do computador host em execuçãoIDT.

Depurar erros de “parâmetro obrigatório ausente”

Como novos recursos estão sendo adicionados IDT gratuitamenteRTOS, alterações nos arquivos de configuração podem ser introduzidas. O uso de um arquivo de configuração antigo pode danificar sua configuração. Se isso acontecer, o arquivo test_group_id__test_case_id.log no diretório results/execution-id/logs listará explicitamente todos os parâmetros ausentes. IDTfor Free RTOS valida seus esquemas JSON de arquivo de configuração para garantir que a versão mais recente suportada tenha sido usada.

Depurar erros do tipo “o teste não pôde ser iniciado”

Você pode encontrar erros que apontam para falhas ao iniciar o teste. Como existem várias causas possíveis, verifique se há algum problema nas seguintes áreas:

Depurar erros de “não foi possível encontrar o início dos resultados do teste”

Você pode ver erros ao IDT tentar analisar a saída de resultados do dispositivo em teste. Existem várias causas possíveis, por isso verifique se há algum problema nas seguintes áreas:

Depure um erro “Falha no teste: resultados esperados __, mas vi ___”

Você pode encontrar erros que apontam para falhas ao iniciar o teste. O teste espera um certo número de resultados e não vê isso durante o teste. Alguns RTOS testes gratuitos são executados antes de IDT ver a saída do dispositivo. Se ver esse erro, tente aumentar o valor de testStartDelayms em sua configuração de dados de usuário. Para obter mais informações, consulte Configuração de parâmetros de compilação, atualização e teste.

Depurar um erro do tipo “________ não foi selecionado devido a restrições” ConditionalTests

Isso significa que você está executando um teste em um grupo de dispositivos que é incompatível com o teste. Isso pode acontecer com os testes OTA E2E. Por exemplo, ao executar o grupo de OTADataplaneMQTT teste e em seu arquivo de device.json configuração, você escolheu OTA como Não ou OTADataPlaneProtocol Como HTTP. O grupo de teste escolhido para execução deve corresponder às suas seleções de capacidade device.json.

Depuração e IDT tempo limite durante o monitoramento de saída do dispositivo

IDTpode atingir o tempo limite devido a vários motivos. Se ocorrer um tempo limite durante a fase de monitoramento da saída do dispositivo de um teste e você puder ver os resultados no registro do caso de IDT teste, isso significa que os resultados foram analisados incorretamente por. IDT Um dos motivos podem ser as mensagens de log intercaladas no meio dos resultados do teste. Se for esse o caso, consulte o Guia de RTOS portabilidade gratuita para obter mais detalhes sobre como os UNITY registros devem ser configurados.

Outro motivo para o tempo limite durante o monitoramento da saída do dispositivo pode ser a reinicialização do dispositivo após uma única falha no caso de TLS teste. O dispositivo executará a imagem instalada e causará um loop infinito que será visto nos logs. Se isto acontecer, o seu dispositivo não será reinicializado após uma falha no teste.

Depurar um erro “não autorizado a acessar o recurso”

Você pode ver o erro”user/role não está autorizado a acessar esse recurso” na saída do terminal ou no test_manager.log arquivo abaixo/results/execution-id/logs. Para resolver este problema, anexe a política gerenciada AWS IoTDeviceTesterForFreeRTOSFullAccess ao usuário de teste. Para obter mais informações, consulte Crie e configure uma AWS conta.

Depurar erros de teste de rede

Para testes baseados em rede, IDT inicia um servidor de eco que se vincula a uma porta não reservada na máquina host. Se você estiver enfrentando erros devido a tempos limite ou conexões indisponíveis nos testes de soquetes seguros WiFi ou de soquetes seguros, certifique-se de que sua rede esteja configurada para permitir tráfego para portas configuradas na faixa de 1024 a 49151.

O teste de soquetes seguros usa as portas 33333 e 33334 por padrão. Os WiFi testes usam a porta 33335 por padrão. Se essas três portas estiverem em uso ou bloqueadas por firewall ou rede, opte por usar portas diferentes em userdata.json para testes. Para obter mais informações, consulte Configuração de parâmetros de compilação, atualização e teste. Você pode usar os seguintes comandos para verificar se uma porta específica está em uso:

OTAfalhas de atualização devido à carga útil da mesma versão

Se os casos de OTA teste falharem devido à mesma versão estar no dispositivo após a execução de umaOTA, pode ser porque seu sistema de compilação (por exemplo, cmake) não percebeu IDT as alterações no RTOS código-fonte gratuito e não criou um binário atualizado. Isso faz com OTA que seja executado com o mesmo binário que está atualmente no dispositivo e o teste falhe. Para solucionar falhas de OTA atualização, comece verificando se você está usando a versão mais recente compatível do seu sistema de compilação.

OTAfalha de teste no caso PresignedUrlExpired de teste

Um pré-requisito desse teste é que o tempo de OTA atualização seja superior a 60 segundos, caso contrário, o teste falhará. Se isso ocorrer, a seguinte mensagem de erro é encontrada no log: “Teste leva menos de 60 segundos (tempo expirado da url) para concluir. Por favor, entre em contato conosco."

Depurar erros de interface e porta do dispositivo

Esta seção contém informações sobre as interfaces de dispositivos IDT usadas para se conectar aos seus dispositivos.

Plataformas compatíveis

IDTé compatível com Linux, macOS e Windows. Todas as três plataformas têm diferentes esquemas de nomenclatura para os dispositivos seriais que se conectam a elas:

Para verificar a porta do dispositivo:

Para verificar qual dispositivo está conectado a uma porta:

Interfaces de dispositivo

Cada dispositivo incorporado é diferente, o que significa que ele pode ter uma ou mais portas seriais. É comum que os dispositivos tenham duas portas quando conectados a uma máquina:

No Windows, siga a mesma lógica.

Leitura de dados de dispositivo

IDTfor Free RTOS usa ferramentas de criação de dispositivos individuais e flash para especificar a configuração da porta. Se você estiver testando o dispositivo e não obtiver a saída, tente as seguintes configurações padrão:

Essas configurações são gerenciadas pelo IDT for FreeRTOS. Você não precisa defini-los. No entanto, você pode usar o mesmo método para ler a saída do dispositivo manualmente. No Linux ou macOS, você pode fazer isso com o comando screen. No Windows, você pode usar um 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 cadeia de ferramentas de desenvolvimento

Esta seção aborda os problemas que podem ocorrer com a cadeia de ferramentas.

Code Composer Studio no Ubuntu

As versões mais recentes do Ubuntu (17.10 e 18.04) têm uma versão do pacote glibc que não é compatível com as versões 7.x do Code Composer Studio. Recomendamos que você instale o Code Composer Studio versão 8.2 ou mais recente.

Os sintomas de incompatibilidade podem incluir:

Registro em log

IDTfor Free, RTOS os registros são colocados em um único local. No IDT diretório raiz, esses arquivos estão disponíveis emresults/execution-id/:

FRQ_Report.xml e logs/test_group_id__test_case_id.log são os logs mais importantes a serem examinados. FRQ_Report.xml contém informações sobre quais casos de teste falharam com uma mensagem de erro específica. Depois, é possível usar logs/test_group_id__test_case_id.log para ver mais detalhes sobre o problema, a fim de obter um contexto melhor.

Erros do console

Quando AWS IoT Device Tester é executado, as falhas são reportadas ao console com mensagens breves. Examine results/execution-id/logs/test_group_id__test_case_id.log para saber mais sobre o erro.

Erros de logs

Cada execução do conjunto de testes tem um ID de execução exclusivo usado para criar uma pasta chamada results/execution-id. Os logs de casos de testes individuais estão no diretório results/execution-id/logs. Use a saída do RTOS console IDT for Free para encontrar o ID de execução, o ID do caso de teste e o ID do grupo de teste do caso de teste que falhou. Em seguida, use essas informações para localizar e abrir o arquivo de log desse caso de teste chamado results/execution-id/logs/test_group_id__test_case_id.log As informações nesse arquivo incluem a saída completa dos comandos de compilação e flash, a saída da execução do teste e a saída mais detalhada AWS IoT Device Tester do console.

Problemas de bucket do S3

Se você pressionar CTRL+C durante a execuçãoIDT, IDT iniciará um processo de limpeza. Parte dessa limpeza é remover os recursos do Amazon S3 que foram criados como parte dos IDT testes. Se a limpeza não puder ser concluída, você poderá ter um problema em que muitos buckets do Amazon S3 foram criados. Isso significa que a próxima vez que você executar IDT os testes começará a falhar.

Se você pressionar CTRL+C para pararIDT, deverá deixá-lo concluir o processo de limpeza para evitar esse problema. Você também pode excluir os buckets do Amazon S3 da sua conta que foram criados manualmente.

Solucionar erros de tempo limite

Se você encontrar erros de tempo limite ao executar um conjunto de testes, aumente o tempo limite especificando um fator multiplicador. Esse fator é aplicado ao valor de tempo limite padrão. Qualquer valor configurado para esse sinalizador deve ser maior que ou igual a 1.0. Para usar o multiplicador de tempo limite, use o sinalizador --timeout-multiplier ao executar o conjunto de testes.

Recurso e AWS cobranças do celular

Quando o Cellular recurso estiver configurado Yes em seu device.JSON arquivo, FullSecureSockets usará EC2 instâncias t.micro para executar testes e isso poderá gerar custos adicionais em sua AWS conta. Para obter mais informações, consulte os EC2preços da Amazon.

Política de geração de relatórios de qualificação

Os relatórios de qualificação são gerados somente pelas versões AWS IoT Device Tester (IDT) que oferecem suporte às RTOS versões gratuitas lançadas nos últimos dois anos. Se tiver dúvidas sobre a política de suporte, entre em contato com o AWS Support.