Desprogramação do AVR

Alguém já teve casos em que um AVR parou de funcionar misteriosamente depois de vários meses, mas a reprogramação o traria de volta?

Estou executando um monte de atmega328 na rede de sensores sem fio. Eu já tive três vezes (em cerca de um ano) quando um deles parou de funcionar. Vou re-gravar o programa nele e ele começará a funcionar novamente. Nem sempre é a mesma unidade, por isso não parece ser um chip com defeito.

Parece que seria uma coisa bastante desastrosa que impediria as pessoas de usar AVRs, por isso é obviamente algo sobre minhas circunstâncias particulares. Eu só estava me perguntando se alguém já se deparou com isso e pode ter algumas dicas.

Como as baterias estão funcionando a 3,3V, a tensão cai muito baixo para funcionar uma vez a cada dois meses e preciso substituir as baterias recarregáveis. Os módulos usam o modo de suspensão e o timer do watchdog para dormir por 60 segundos, fazer uma leitura, enviá-lo por rádio de volta à estação base e depois dormir novamente. Os módulos são compatíveis com o arduino, então eu não virei o bit "não me deixe re-queimar isso".

Você está usando BOD? Ocasionalmente, coisas desagradáveis ​​podem acontecer se um chip escurecer.

Provavelmente o Brown-Out-Detection é o caminho certo, mas ...

Eu tinha um problema apenas de software que causava sintomas muito semelhantes, embora muito mais rapidamente. Acredito que algum C ++ ruim (compilação?) Resultou em corrupção da pilha e a função retornou fora do programa real, executando instruções aleatórias. Não sei ao certo o que aconteceu a seguir, mas a única maneira de corrigi-lo era reativar o programa (aparentemente algumas dessas instruções aleatórias incluíam a gravação na memória do programa).

O bug era apenas um destruidor sendo chamado na hora errada. Tornar a variável global (para que nunca fosse destruída) resolveu o problema. O problema era facilmente reproduzível (demorava cerca de um minuto para disparar) e com energia muito estável. A configuração específica foi o Arduino + WaveShield usando a biblioteca WaveHC, mas acho que isso pode acontecer com qualquer pessoa que use C ++.

Se você preferir linguagens de baixo nível, acidentalmente fiz a mesma coisa na montagem, mas milagrosamente isso nunca causou nada além de problemas de tempo esporádicos: a maioria das instruções tem 2 bytes de comprimento, mas algumas são maiores, e eu calculei a distância do salto e pulei no meio de uma instrução de 4 bytes. Ele foi realinhado rapidamente, mas não é difícil imaginar algo assim em um caminho de código raramente usado, causando insanidade.

Também vi capacitores de desacoplamento Vcc insuficientes / mal posicionados / ausentes causar efeitos semelhantes. Você tem desacoplamento local o mais próximo possível do IC? (100nF - 1uF é o tipo cerâmico)

Outro fator que pode causar perda de memória dos dispositivos são as descargas eletroestáticas (ESD).

A colocação de alguns varistores em todos os conectores externos que estão sujeitos à exposição pode aliviar esse problema. Eu já vi isso em alguns produtos comerciais baseados em microcontroladores Microchip PIC, por isso não é inédito.

Existem alguns varistores úteis que também funcionam como capacitores de filtro (da ordem de 10-150 pF). Verifique estes http://www.tdk.co.jp/tefe02/e9c11_avr.pdf

Eles são pequenos, baratos e protegerão seu dispositivo. Coloque-os o mais próximo possível dos conectores que trazem sinais externos para a placa e direcione todos os traços imediatamente para longe dos pinos do conector.