O que poderia fazer com que um microcontrolador fosse reiniciado inesperadamente?

Uma variedade de bug particularmente irritante em um sistema controlado por microprocessador é o reinício inesperado do microprocessador. Uma ferramenta importante para depurar esse tipo de problema é uma lista de possíveis causas. O que poderia fazer com que um microcontrolador fosse reiniciado inesperadamente?

Nos chips PIC e dsPIC, observei as seguintes causas de redefinição inesperada.

Hardware:

• Reinicie o pino acionado baixo ou flutuando. Verifique as coisas óbvias primeiro!
• Acoplamento ESD no pino de redefinição. Eu já vi isso acontecer quando equipamentos completamente independentes são ligados na mesma mesa. Verifique se há capacitância suficiente no pino de redefinição, possivelmente até 1 uF.
• Acoplamento ESD em outros pinos do processador. As sondas de escopo, em particular, podem atuar como antenas, acoplar ruídos no chip e causar redefinições estranhas. Ouvi relatos de códigos de redefinição "opcode inválido".
• Junta de solda ruim / ponte intermitente. Pode estar perdendo ou causando curto-circuito em um trilho de energia, no processador ou em outro lugar na placa.
• Falha / ruído no trilho de potência. Pode ser causado por vários problemas externos, incluindo um regulador danificado ou uma queda no suprimento a montante. Verifique se os trilhos de energia que alimentam o processador estão estáveis. Pode exigir mais limite em algum lugar, talvez desacoplando o limite diretamente no processador.
• Alguns microcontroladores possuem um pino Vcap, que não deve ser conectado ao VDD e deve ter seu próprio capacitor em comum. Não conectar corretamente este pino pode ter resultados imprevisíveis.
• Dirigir uma entrada analógica negativa além de um certo limite causa uma redefinição que é reportada no RCON como uma queda de energia. O mesmo pode acontecer com as entradas digitais.
• Um dV / dt muito alto em um conversor de energia próximo pode causar uma redefinição de queda de energia. (Veja esta pergunta .) Eu já vi isso em dois casos, e em um consegui rastreá-lo até o acoplamento capacitivo. Um IGBT estava alternando entre 100 e 200 amperes e, no desligamento, alguns circuitos de feedback observavam alguns microssegundos de ruído, passando de 2V para mais de 8V em um processador de 3,3V. Aumentar a tampa do filtro nesse trilho de feedback fez com que as redefinições parassem. Pode-se imaginar que adicionar um filtro dV / dt através do transistor poderia ter tido um efeito semelhante.

Programas:

• Temporizador de vigilância. Verifique se o cronômetro do watchdog é limpo com bastante frequência, especialmente nas ramificações do seu código que podem levar muito tempo para serem executadas, como a EEPROM escreve. Teste para isso desativando o watchdog para ver se o problema desaparece.
• Divida por zero. Se você estiver executando uma operação de divisão no seu código, verifique se o divisor nunca pode ser igual a zero. Adicione uma verificação de limites antes da divisão. Não esqueça que isso também se aplica às operações do módulo .
• Estouro de pilha. Muitas chamadas de função aninhadas podem fazer com que o sistema fique sem memória dinâmica para a pilha, o que pode causar falhas em pontos incomuns na execução do código.
• Pilha com fluxo insuficiente. Se você estiver programando no assembler, poderá acidentalmente executar mais RETURNs do que CALLs.
• Rotina de interrupção inexistente. Se uma interrupção estiver ativada, mas nenhuma rotina de interrupção for definida, o processador poderá redefinir.
• Rotina de armadilha inexistente. Semelhante a uma rotina de interrupção, mas diferente o suficiente, estou listando-a separadamente. Eu vi dois projetos separados usando o dsPIC 30F4013, que são redefinidos aleatoriamente, e a causa foi rastreada para uma armadilha que foi chamada, mas não definida. Claro, agora você tem a pergunta de por que uma armadilha é chamada em primeiro lugar, o que pode ser uma série de coisas, incluindo erro de silício. Mas definir todos os manipuladores de armadilhas provavelmente deve ser um bom passo inicial no diagnóstico de redefinições inexplicadas.
• Falha no ponteiro de função. Se um ponteiro de função não apontar para um local válido, desreferenciar o ponteiro e chamar a função apontada pode causar uma redefinição. Uma causa divertida disso foi quando eu estava inicializando uma estrutura, com valores sucessivos de NULL (para um ponteiro de função) e -1 (para um int). A vírgula foi digitada e, portanto, o ponteiro da função foi inicializado como NULL-1. Portanto, não assuma que apenas por ser um CONST, ele deve conter um valor válido!
• Índice de matriz inválido / negativo. Verifique se você executou a verificação de limites em todos os índices da matriz, limites superior e inferior, se aplicável.
• Criando uma matriz de dados na memória do programa maior que a maior seção da memória do programa. Isso pode nem gerar um erro de compilação.
• Converter o endereço de uma estrutura em um ponteiro para outro tipo, desreferenciar esse ponteiro e usar o ponteiro desreferenciado como LVALUE em uma instrução pode causar uma falha. Veja esta pergunta . Presumivelmente, isso também se aplica a outros comportamentos indefinidos.

Em alguns dsPICs, o registro RCON armazena bits indicando a causa da redefinição. Isso pode ser muito útil ao depurar.

O pino RESET deve ser acionado adequadamente por um circuito de redefinição que monitora a tensão acima / abaixo e cria um sinal de redefinição por tempo suficiente. Com isso em mente, minhas experiências com uma redefinição descontrolada de hardware vêm de:

• Diafonia de alternar linhas para o pino / linha RESET (reduza)
• Mudanças de terra / loop causadas pela ativação / desativação de carga externa de alta corrente
• Pico de tensão não filtrado pela fonte de alimentação e muito curto para ativar o RESET adequado
• Trocar cargas externas pelo microcontrolador que causa problemas acima (principalmente em cargas indutivas, como ligar / desligar o motor, relés ou lâmpada antiga (corrente de irrupção)
• O pico de tensão / corrente em qualquer um dos pinos do microcontrolador (o pior é o oscilador) pode causar corrente reversa e pode alternar o registro interno (o mesmo que o pico de tensão na linha de alimentação). Em geral, ao fazer interface com um tipo de ambiente industrial, é preciso ter cuidado (para mais informações, consulte: http://www.ichaus.biz/wp1_mcu_interface ). É necessário considerar a mudança de nível nas entradas / saídas, filtragem de entrada e saídas de comutação suave. Limpar as linhas de suprimento tem a primeira prioridade no lado do hardware. Em seguida, RESET e pinos do oscilador e, em seguida, linhas IO. -milímetros

Uma possibilidade adicional que não vi nesta lista é um dispositivo que suporta ICSP. Se pull ups insuficientes forem usados ​​em linhas que disparam no modo de programação serial em circuito, às vezes é possível entrar nesse modo aleatoriamente. Isso leva a uma redefinição um intervalo curto mais tarde, quando nenhuma atualização do programa é enviada para as linhas do receptor serial designadas. Suspeito que um cronômetro interno de vigilância for reiniciado se o ICSP for iniciado e nenhum dado de programação for enviado. Este é um erro que cometi e passei muito tempo encontrando com uma 16F876.

Verifique se você está usando chips lógicos CMOS ou TTL em seu circuito, se eles possuem capacitores de desacoplamento adequados em Vdd e terra (geralmente 0,1 uF). Eu estava usando um CD4021 em um design e, quando estava em uso, aparentemente estava causando um pico que estava causando a reinicialização do microprocessador. Então o ciclo se repetiria. É também por isso que é uma boa ideia colocar uma sequência de teste óbvia (como piscar e apagar um LED algumas vezes) no início do seu código para que você saiba que o microprocessador está trabalhando e executando o código.

Esta é uma daquelas coisas raras que podem aparecer:

Eu tinha um projeto que envolvia um microcontrolador e ele se redefinia esporadicamente. Para encurtar a história, parece que alguma opção teve que ser ativada ou desativada, caso contrário as redefinições poderão ocorrer. Eu só descobri isso lendo as erratas depois de desistir de todo o resto.

Agora, tenho o hábito de ler as erratas antes mesmo de decidir usar um chip para saber no que estou me metendo e se é algo que posso gerenciar. Infelizmente, depois da formatura, eu realmente não tinha ninguém para me educar sobre práticas comuns, e muito do meu aprendizado no mundo real passou por fracassos e frustrações.