Corrupção de memória flash AVR

11

Esta questão está relacionada à própria desprogramação do AVR .

Informações do projeto:
Temos um produto alimentado por bateria usando um ATMEGA644P. O aplicativo é executado permanentemente no modo de suspensão e acorda apenas uma vez por segundo (RTC) ou quando uma das duas linhas de interrupção externas é acionada.

O dispositivo possui um carregador de inicialização bastante simples que está se comunicando pelo UART (usando o IC da interface RS232). Ele serve apenas como um método conveniente para atualizar o firmware, para que nenhum programador de ISP de hardware seja necessário. (O carregador de inicialização espera telegramas seguros com soma de verificação)

Os dispositivos foram projetados com desativação interna desativada porque duplica o consumo de energia e a bateria de longa duração é obrigatória (acho que uma detecção de desativação externa deveria ter sido usada - um novo design está em andamento).

Problema:
Todos os meses, um dispositivo para de funcionar, NENHUMA atualização de firmware é executada nesses dispositivos. No entanto, após um exame mais aprofundado, o conteúdo do flash desses dispositivos parece estar corrompido. Além disso, as baterias de alguns desses dispositivos ainda estavam boas, mas não quero descartar algum tipo de situação de subtensão.

Esta é uma comparação do conteúdo original do flash (à esquerda) com o conteúdo corrompido (à direita):

Comparação Flash

Algumas observações:

Um bloco corrompido sempre consiste em pelo menos uma página flash (256 bytes) e está alinhado. Em outras palavras: Somente páginas inteiras são afetadas, não bytes únicos.
O conteúdo corrompido lê 0xFF na maioria das vezes, mas também pode conter alguns outros valores ou ser completamente "aleatório".
A pequena barra no lado esquerdo da imagem mostra todas as áreas afetadas. Para este dispositivo, é cerca de um décimo do conteúdo total do flash.
Tínhamos um dispositivo em que apenas uma única página foi afetada.

É totalmente plausível que uma condição de subtensão ao gravar a memória flash possa corromper o conteúdo do flash. No entanto, isso significa que algumas instruções sensíveis ao flash precisam ser executadas.

Talvez o controlador esteja reiniciando aleatoriamente devido à subtensão e o código do carregador de inicialização esteja agindo totalmente imprevisível durante esse período. Para citar alguém de outro fórum sobre subtensão:

"Não são apenas instruções aleatórias do flash sendo executadas, mas também um período de instruções aleatórias (não há garantia de que o código do flash seja lido e interpretado corretamente). Junto com isso, outras partes do mcu podem não se comportar como projetadas, incluindo proteção mecanismos ".

Pergunta (s):
Você acha que o "comportamento aleatório durante a subtensão e a execução de algumas instruções alterando os dados em páginas flash" - a explicação é correta? Se for esse o caso, por que não vemos esse tipo de erro o tempo todo, apenas como causa de alguns problemas de software (estouro de pilha, ponteiros inválidos).

Você tem alguma outra idéia do que poderia causar esse tipo de corrupção? Isso pode ser causado por EMI / ESD?

— Rev1.0
fonte

No segundo bloco do seu exemplo, alguns bits passaram de 1-> 0 ou todas todas as transições 0-> 1? Eu tenho um script que calcula isso, mas não vou digitar todos os números da sua captura de tela.

— markrages

@markrages: Ao olhar para ele, apenas 0-> 1. Uma resposta também apontou que parece uma exclusão parcial, onde nem todos os bits foram alterados para 1. Obrigado pela observação.

— Rev1.0

11

Você deve observar que o flash não está gravado, é apagado. Um flash apagado está cheio de 0xFF. Seus primeiros 256 bytes são totalmente apagados, sua terceira região de 256 bytes é parcialmente apagada (você só tem 0 a 1 bitflips dos dados corretos para os corrompidos).

De acordo com a folha de dados , esse flash pode ser apagado na página (geralmente trabalho com blocos de apagamento maiores que as páginas). Como visto na página 282, é fácil executar o Apagar página pelo SPM.

Você pode estar interessado na seção 23.8.1 (Evitando a corrupção do Flash):

A corrupção do programa Flash pode ser causada por duas situações em que a tensão está muito baixa. Primeiro, uma sequência de gravação regular no Flash requer uma voltagem mínima para funcionar corretamente. Em segundo lugar, a própria CPU pode executar instruções incorretamente, se a tensão de alimentação para a execução de instruções for muito baixa. A corrupção do Flash pode ser facilmente evitada seguindo estas recomendações de design (uma é suficiente):

Se não houver necessidade de uma atualização do Boot Loader no sistema, programe os bits de bloqueio do Boot Loader para impedir atualizações de software do Boot Loader.

Mantenha o AVR RESET ativo (baixo) durante períodos de tensão insuficiente da fonte de alimentação.
Isso pode ser feito ativando o Detector Brown-out (BOD) interno se a tensão operacional corresponder ao nível de detecção. Caso contrário, pode ser usado um circuito externo de proteção de redefinição do VCC. Se ocorrer uma redefinição enquanto uma operação de gravação estiver em andamento, a operação de gravação será concluída desde que a tensão da fonte de alimentação seja suficiente.

Mantenha o núcleo do AVR no modo de suspensão de energia durante períodos de baixo VCC. Isso impedirá que a CPU tente decodificar e executar instruções, protegendo efetivamente o Registro SPMCSR e, portanto, o Flash contra gravações não intencionais.

— Jacen
fonte

Sua observação sobre a exclusão parcial na terceira página parece plausível. Em relação ao texto Atmel: Todos concordamos que o BOD parece ser obrigatório. Mas ainda não tenho certeza sobre a causa exata da corrupção. Não é muito improvável que o controlador apenas execute (por causa da baixa tensão) esta instrução específica para apagar uma página flash? Quero dizer, isso teria que acontecer durante a execução do código do carregador de inicialização, uma vez que o flash é gravável apenas a partir daí. E isso requer uma sequência específica.

— Rev1.0

3

Não é possível explicar a fonte exata da corrupção: quando o seu Vcc cai, fica muito baixo para saturar completamente um transistor com outro. Um MCU é basicamente uma equação lógica muito grande. Se seus transistores param de se comportar como comutadores lógicos, você altera esta equação. Como o primeiro transistor a se comportar mal depende do doping do ASIC Wafer e de perturbações eletromagnéticas externas, você não pode prever o que acontecerá. Para solucionar esse problema, ao projetar seu ASIC, você pode adicionar uma parte analógica que desativa a parte digital antes de se comportar mal. Mas aumenta todo o custo ASIC.

— Jacen 26/06

Confuso que a nota do aplicativo AVR180 External Brown-out Protection declare: "Observe que o conteúdo interno da memória do programa Flash AVR® nunca é afetado pela tensão insuficiente da fonte de alimentação". Além disso: "Como a CPU do AVR não é capaz de gravar na própria memória do programa, o conteúdo interno da memória do Programa Flash nunca é afetado por uma situação de falha de energia". - O IMO Atmel está apenas ignorando que há algo como os carregadores de inicialização que TEM QUE mudar o mem flash.

— Rev1.0

@ Rev1.0 Bem, sim, é bastante improvável ... é por isso que você só o vê em um dispositivo a cada poucos meses, e não em todos os dispositivos o tempo todo.

— usar o seguinte comando

"Quero dizer, isso teria que acontecer durante a execução do código do carregador de inicialização, já que o flash é gravável apenas a partir daí". - Isso só é verdade se os bits de bloqueio de inicialização ( BLB01e amigos) estiverem definidos adequadamente! São eles? "Confuso ... nota de aplicação ..." - As notas de aplicação são notoriamente não confiáveis. Use-os apenas para inspiração; para obter garantias, confie nas folhas de dados (que também não são infalíveis, mas ei).

— marcelm

4

Esse é um problema bem conhecido e afeta muitos microcontroladores (não apenas o Atmel). O hardware de controle da memória flash corrompe ou apaga parte da memória em condições de baixa tensão. A solução simples é ativar a proteção de escurecimento.

Você sempre deve ativar a proteção de escurecimento dos microcontroladores.

— do utilizador
fonte

3

Você tem alguma referência sólida sobre COMO e POR QUE "o hardware de controle de memória corrompe ou apaga parte da memória em condições de baixa tensão"? Existem muitas discussões no fórum sobre corrupção de flash, mas quase nunca se resume a algo sólido, e foi por isso que perguntei aqui.

— Rev1.0

É um problema de subtensão no chip ou está relacionado à execução incorreta / aleatória de programa na seção gerenciador de inicialização, na qual o AFAIK pode modificar apenas o FLASH. Se o segundo for um problema, desativar a execução do gerenciador de inicialização via FUSE deve resolver o problema.

— TMA

Lembro-me de ler sobre isso nas erratas de pelo menos um micro MEGA.

— usuário

3

A subtensão é uma causa muito provável. Por exemplo, uma vez eu tive um projeto em que um nível de queda de 1,8 V causava frequentemente corrupção, e essas corrupções nunca podiam ser reproduzidas com um nível de queda de 3,5V.

Observe que, quanto mais rápido o processador roda, mais sensível é a problemas de subtensão. Se a redução da frequência da CPU for uma opção disponível para você, pode valer a pena tentar.

— vsz
fonte

1

Obrigado pela resposta. Acabamos usando um detector externo de queda de energia de ultra baixa potência e não tivemos problemas de corrupção desde então.

— Rev1.0 14/05

0

A EMC será seu maior inimigo, se você não seguir as principais regras de design de placas de circuito impresso. Aqui estão os mais importantes da minha própria experiência: - bloqueio de capacitores em qualquer IC, independentemente do que os fabricantes dizem em suas planilhas de dados sobre esquemas infernais, coloque pelo menos um entre 100pF - 1nF nas linhas de energia de cada IC - conduzindo áreas de terra em camada de cada PCB, tanto quanto possível. Essas áreas devem ser contatadas por todas as camadas por vias sempre que possível; uma grade de 50mil é um bom valor. Conecte essas áreas ao sinal de aterramento. - Nunca deixe cobre desconectado (flutuante, sem sinal conectado) na sua PCB. Ele age como uma antena e coloca deliberadamente radiação eletromagnética nos dispositivos - faça traços que transmitem sinais de relógio o mais curto possível

Encontre mais detalhes nas solicitações de mecanismos de pesquisa como "guia para design de PCB à prova de EMC"

— woodz
fonte