Utilizamos microcontroladores ATmega48 / 88/168/328 há muitos anos com sucesso em muitos de nossos produtos. Agora, consideramos mudar das variantes A e PA para a nova variante PB (porque precisaremos de pinos, temporizadores e UARTs extras em novos produtos, porque ficou mais barato e porque parece que as variantes antigas serão descontinuadas), então trocamos um ATmega328A por um ATmega328PB. Parece ficar muito confuso após interrupções de energia . Tais problemas nunca ocorreram com as variantes antigas.

Interrupções regulares de energia são normais para o uso dos nossos produtos. Usamos uma fonte de alimentação comutada (como esta ) configurada para 5V e temos capacitores na faixa de 220µF no VCC do ATmega, para manter a SRAM ativa para interrupções de energia na faixa de vários minutos, para armazenar estados internos que não são missão crítico, mas aumenta significativamente a experiência do usuário ao estar instantaneamente disponível em uma reinicialização (esses estados mudam com frequência suficiente para tornar a EEPROM inadequada). Isso sempre funcionou.

No entanto, com o novo ATmega328PB, após uma interrupção de energia, o chip é redefinido sem que uma condição de redefinição seja encontrada no MCUSR, e o relógio parece dar errado.

• o detector de escurecimento é definido por fusível. Tentamos todos os níveis corporais disponíveis, o bug ocorre em todos eles.
• usamos 20 MHz externos, também configurados corretamente por fusível.
• tentamos 3 chips diferentes, portanto não houve uma única solda ou outra falha de hardware.

Depois que o bug ocorre, o relógio geralmente se ajusta à velocidade 2,5x mais lenta, indicando que o mcu está sendo sincronizado pelo oscilador interno de 8 MHz. No entanto, às vezes a desaceleração é de cerca de 6x. Isso significa que não pode ser um erro de software alterar o divisor de relógio, pois não consigo definir os fusíveis do software e o divisor de relógio não pode dividir o relógio por 2,5 ou 6.

Então, meu primeiro suspeito foi o novo fusível de detecção de falha de relógio. No entanto, não importa se está ligado ou desligado, o comportamento permanece o mesmo.

Para descartar as peculiaridades do software, escrevi um programa de teste simples do zero, que não faz nada além de alternar uma saída com 100 Hz de uma interrupção do timer e indica com LEDs após cada reinicialização quais condições de redefinição foram ativadas (conforme lido no MCUSR). O restante do hardware também foi removido, apenas o MCU e o regulador estão lá (e o indicador leds com resistores em série).

Os resultados

Aproximadamente 2/3 das vezes, nada de interessante acontece. Após a interrupção de energia, o mcu retoma seu trabalho, os indicadores de redefinição de escurecimento e de inicialização quando acendem.

(na imagem, vermelho é o pino de alternância e azul é VCC. Nesta imagem, a saída de 2,7 V é claramente visível. Fiz os mesmos testes com as outras configurações de queda de energia, os resultados são exatamente os mesmos, então eu vou omitir essas fotos)

Aproximadamente 1/3 do tempo, o bug mencionado ocorre e, quando a energia volta novamente, nenhum dos indicadores de redefinição de energia e de apagamento acesas acende! A saída é diferente, como se o MCU estivesse correndo com um relógio estranho. Não é caótico, no entanto, continua correndo com a mesma frequência.

Curiosamente, nessa situação, o detector de escurecimento parece estar completamente inativo, porque após a próxima interrupção de energia (onde o relógio correto é restaurado algumas vezes, outras vezes não), é claramente visível que a saída continua alternando bem após a o nível de saída foi passado. Nessas situações, o relógio às vezes fica mais rápido, outras vezes, mais lento:

Durante esses testes, usei 16K CK / 14CK + 4.1 ms para o atraso de inicialização (mas o atraso de 65 ms não evita os problemas).

Aqui está uma imagem ampliada, onde você pode ver claramente que o VCC atinge um estado estável a 5 V em menos de 2 ms:

Na figura acima, o MCU foi iniciado corretamente.

Curiosamente, quando isso não ocorre, a tensão de alimentação chega a 5 V estáveis ​​ainda mais cedo (parece que muitas partes do mcu não ligam, portanto, consome menos corrente durante a inicialização)

Abaixo está uma imagem de um início malsucedido:

Observe que o software começa a funcionar após mais de 85 ms após a estabilização da tensão de alimentação, em vez dos 10,5 ms exigidos em contrário. Os fusíveis para o atraso de inicialização ainda são os mesmos, 16K CK / 14CK + 4.1 ms.

O que também é interessante notar é que, após o desligamento da fonte, o VCC se estabiliza em torno de 1,1 a 1,2 Volts (a antiga variante ATmega328A caiu para cerca de 0,6 - 0,7 V). Mantém isso por vários minutos. Se eu esperar o suficiente (da ordem de meia hora ou mais), o mcu sempre inicia corretamente! Portanto, parece que o problema é que há 1,1 Volt ao redor, o que, de acordo com a folha de dados, não é garantido como suficiente para uma reinicialização na inicialização. Mas isso deve ser suficiente para uma reinicialização ociosa!

Exceto nessas situações, o detector de escurecimento funciona bem. É visível na primeira imagem (o sinal de saída para quando o nível do corpo é atingido e a queda de tensão diminui à medida que partes do mcu são desligadas). Fiz testes quando reduzi o VCC para um pouco abaixo do nível do corpo e o deixei subir novamente, o mcu sempre reiniciou corretamente nessas condições, com apenas o indicador de reset aceso.

Perdi alguma coisa óbvia ou o ATmega328PB tem um bug sério em seu detector de escurecimento?

EDITAR:

Curiosamente, os problemas acima só surgem quando interrompo o fornecimento antes do regulador. Se eu o interromper após o regulador (ou usar uma fonte de alimentação de laboratório), os problemas nunca acontecerão. Como se o formato da tensão crescente causasse os problemas. No entanto, como você pode ver na última imagem, o aumento da tensão é bastante agradável e estabiliza rapidamente.

EDIT 2

Eu tentei com 16 MHz em vez de 20 MHz, mas exatamente os mesmos problemas acontecem.

Não acho que seja um bug no detector de escurecimento, mas como você usa o chip.

Como você mesmo disse, o limite de redefinição de inicialização de 1,1 V não será atingido se a energia for removida e conectada brevemente, portanto não haverá POR.

Detector marrom-out também não pode ajudar muito. Você está usando o AVR a 20 MHz e isso exige que a tensão de alimentação seja de 4,5 V ou mais ou está violando as especificações. E o BOD não garante que ele disparará a 4,5 V, normalmente é menor que isso, digamos 4,3 V. Portanto, mesmo antes do BOD ser acionado, não há garantia em que estado o AVR termina, mas o BOD deve ser acionado, exceto que pode não funciona devido ao seu relógio de 20 MHz. Quando a tensão começa a subir novamente, o DBO é desativado antes que a tensão de alimentação esteja novamente em um nível seguro de 4,5 V. Se foi acionado corretamente. O tempo de atraso de inicialização deve ser definido como alto o suficiente para que a tensão mude para subir do nível de desativação de DBO para 4,5 V antes que o reset interno seja liberado.

Mas tudo pode falhar porque só precisa de pelo menos 4,5 V para rodar a 20 MHz. A folha de dados do AVR menciona que, se o sistema de redefinição interna não for adequado, use um chip de redefinição externa e, nesse caso, parece que resolveria seus problemas para redefinir o AVR antes que a tensão caia para 4,5 V.