ASM51

Pessoal,

Estou com um problema em um projeto, de vez em quando algumas posições da EEPROM aparecem com os dados corrompidos.

Isso acontece quando tiro a alimentação e ligo novamente, a EEPROM não é acessada muitas vezes, na verdade na inicialização e depois em dois comandos acessados via serial ... (leitura), a escrita é feita somente em um comando via serial que ocorre a pedido do usuário.

O AVR que uso é o ATMEGA64, já ativei os fuses "BODEN" e "BODLEVEL" e ajudou muito, reduziu bastante o problema, quase poderia dizer que ficou 100%, mas ainda teve um episódio que corrompeu os dados ... e pelo projeto precisa ficar 100% !

Existe ainda mais algum macete para evitar dos dados sejam corrompidos na EEPROM ?

Abraço

Olá Jairo,

Tem capacitor de 100 nF entre VCC e GND próximo ao mcu ?

A fonte de alimentação pode estar gerando ruído. Veja no osciloscópio com o circuito alimentado e durante essa transição, quando ligar o circuito. Verifique a fonte com uma carga resistiva, sem alimentar o circuito do mcu.

Tem alguma fonte de rf próxima ? Motor ? Lâmpada fluorescente ? Monitor de tubo ? TV de tubo ?

[]s
Jorge

Tem certeza que o acesso não está sendo feito muito rápido, alem da velocidade permitida pela EEPROM ?
Tem casos em que o core com cristal muito alto precisa de delays dentro da função I2C.

Outra coisa é a seleção do valor dos resistores de pull-up apropriados.



+++

ATmega64 EEPROM Write During Power-down Sleep Mode

When entering Power-down Sleep mode while an EEPROM write operation is active, the EEPROM write operation will continue, and will complete before the Write Access time has passed. However, when the write operation is completed, the oscillator continues running, and as a consequence, the device does not enter Power-down entirely. It is therefore recommended to verify that the EEPROM write operation is completed before entering Power-down.

ATmega64 Preventing EEPROM Corruption

During periods of low VCC, the EEPROM data can be corrupted because the supply voltage is too low for the CPU and the EEPROM to operate properly. These issues are the same as for board level systems using EEPROM, and the same design solutions should be applied.
An EEPROM data corruption can be caused by two situations when the voltage is too low. First,
a regular write sequence to the EEPROM requires a minimum voltage to operate correctly. Secondly, the CPU itself can execute instructions incorrectly, if the supply voltage is too low.
EEPROM data corruption can easily be avoided by following this design recommendation:
Keep the AVR RESET active (low) during periods of insufficient power supply voltage. This can be done by enabling the internal Brown-out Detector (BOD). If the detection level of the internal BOD does not match the needed detection level, an external low VCC Reset Protection circuit can be used. If a reset occurs while a write operation is in progress, the write operation will be completed provided that the power supply voltage is sufficient.

O macete é consistência por software.
Para os parametros eu sempre gravo valores dobrados em estruturas com checksum ao final, e sempre escrevo em operações separadas. Dessa forma, se der pau durante a escrita de um novo valor, o valor antigo continua preservado.
No caso de ponteiro para fila e listas, eu crio a estrutura de controle duplicada e também faço a atualização em operações separadas. Dessa forma, se der pau perco somente a ultima atualização.

lopesjm escreveu:Olá Jairo,

Tem capacitor de 100 nF entre VCC e GND próximo ao mcu ?

A fonte de alimentação pode estar gerando ruído. Veja no osciloscópio com o circuito alimentado e durante essa transição, quando ligar o circuito. Verifique a fonte com uma carga resistiva, sem alimentar o circuito do mcu.

Tem alguma fonte de rf próxima ? Motor ? Lâmpada fluorescente ? Monitor de tubo ? TV de tubo ?

[]s
Jorge

Jorge,

Alimentação é via USB, estou usando capacitor entre VCC e GND, e não possui nenhuma fonte de interferência perto ...

tcpipchip escreveu:During periods of low VCC, the EEPROM data can be corrupted because the supply voltage is too low for the CPU and the EEPROM to operate properly. These issues are the same as for board level systems using EEPROM, and the same design solutions should be applied.
An EEPROM data corruption can be caused by two situations when the voltage is too low. First,
a regular write sequence to the EEPROM requires a minimum voltage to operate correctly. Secondly, the CPU itself can execute instructions incorrectly, if the supply voltage is too low.
EEPROM data corruption can easily be avoided by following this design recommendation:
Keep the AVR RESET active (low) during periods of insufficient power supply voltage. This can be done by enabling the internal Brown-out Detector (BOD). If the detection level of the internal BOD does not match the needed detection level, an external low VCC Reset Protection circuit can be used. If a reset occurs while a write operation is in progress, the write operation will be completed provided that the power supply voltage is sufficient.

TCPIPCHIP,

Já havia lido isso no datasheet, por isso ativei os fuses "BODEN" e "BODLEVEL" (Brown-out Detector (BOD)), e fez uma grande diferença ...

Aquino escreveu:O macete é consistência por software.
Para os parametros eu sempre gravo valores dobrados em estruturas com checksum ao final, e sempre escrevo em operações separadas. Dessa forma, se der pau durante a escrita de um novo valor, o valor antigo continua preservado.
No caso de ponteiro para fila e listas, eu crio a estrutura de controle duplicada e também faço a atualização em operações separadas. Dessa forma, se der pau perco somente a ultima atualização.

Aquino,

Era uma alternativa que estava pensando ... gravar dobrado em outra posição e fazer um check ...

Fiz alguns testes ontem e não consegui simular mais o problema, na verdade depois que ativei os fuses "BODEN" e "BODLEVEL", tive problema uma vez e aconteceu depois que fiz um curto na alimentação quando estava medindo um sinal com o osciloscópio.

Por garantia vou gravar os dados dobrados e fazer um check mesmo.

Obrigado pessoal !