Flash do PIC corrompendo em campo !?!?!?

[guest2003]

Pessoal,

Chegou uma peça aqui para manutenção e fiquei preocupado com o defeito...

A memoria de programa do PIC estava corrompida... simplesmente regravei o PIC e o produto ficou perfeito.

Agora pergunto, como pode acontecer isso ?!!? e como evitar !?!?

Alguem ja viu alguma coisa assim ?!!?

[]'s

[Vonnilmam]

Olha só!

Poderia ser diversos fatores, desde uma rotina que executa alguma função proibida na arquitetura do pic "podendo" simular uma função que mexa na memória de programa! (coisa pouco provável, mas possivel!).

O que vc relata, já aconteceu comigo também, tenho varios produtos rodando no mercado utilizando o mesmo sistema operacional de gerenciamento, apenas são mudadas as funções de painel...

Já me foi enviado chips que tinham seu funcionamento "aleatório" (coisa inimaginavel dentro do programa original).

Após ter regravado o pic (no caso foi um F877A-I/P) o mesmo funcionou corretamente.

Fato é que eu naquela dúvida, fiz uma revisão geral e minuciosa em todo o programa e não constatei nenhum erro!...

Vai ver que é assombração....rsrs,

[Djalma Toledo Rodrigues]

Seria o Gravador do PIC ?

Verique as tensões dele, especialmente o 13.5 Vdc
.

[guest2003]

O PIC em questão é o PIC16F689 ele não consegue se auto-escrever, portanto a questão do proprio PIC corromper a memoria não seria o caso neste PIC.

Djalma, estou gravando usando o PICkit2, segundo o manual do PIC o VPP pode ser de 10 a 12V, mas não entendi sua colocação, pois o PIC foi gravado e o produto saiu daqui funcionando normalmente... depois de um tempo ele voltou sem funcionar, e o problema era a memoria flash corrompida.

[]'s

[rona123]

guest2003

Eu tive alguns problemas equivalentes com o F4550.

[]s
rona123

[Sergio38br]

Tive um problema parecido em um equipamento que operava em campo aberto, sujeito a chuva e trovoadas, a unica maneira que consegui resolver, foi acrescentar um supervisor para o micro (max1232) , comandado pelo clock do proprio micro.

[ ]`s
Sergio

[KrafT]

Vai que tentaram copiar teu produto?

[Red Neck Guy]

Eu tive problemas parecidos mas era um mcu de outra arquitetura. Resolvi na época acrescentando um TVS na entrada e um indutor de modo comum na entrada da fonte. Claro que era de outra arquitetura e fabricante mas no meu caso resolveu pois nunca mais aconteceu e o problema era frequente.

[guest2003]

Obrigado pelas ideias e sugestoes pessoal,

Este projeto roda em ambiente automotivo, vou dar uma melhorada na fonte... ja tem bastante por ai rodando e este foi o primeiro problema deste tipo, vamos ver se para por ai...

[]'s

[jack sparrow]

Oi Guest2003,
Tenho um produto automotivo que frequentemente apresentava esse problema quando algum curioso mexia na instalação e desligava a alimentação do equipamento mas deixava entradas de sinal ou sensores ligados que levavam tensão a pinos do Pic com o mesmo sem alimentação; ai o Pic era alimentado pelo pino então o Sw bixava. Resolvi colocando todas as entradas com pull up e acopladores opticos mandando terra aos pinos quando ativados.

[_blackmore_]

...Este projeto roda em ambiente automotivo...[]'s

bom .. posso dizer que tome cuidado não apenas com a fonte, mas tb filtrar qqer ruído que qqer outro equipamento ou circuito no veículo possa lhe causar problemas.
Um exemplo, um pico de tenção de um motor de ar condicionado causava uma tensão reversa de de 130 volts no produto que temos ... adivinha o que acontecia com o microcontrolador?

abrax!

[Flaviofrc]

Só uma coisa.....

De uma olhada na configuração do LVP (low voltage programer)

Se que pode ser uma bobagem mas as vezes....

[jandom]

TIVE PROBLEMAS TAMBEM EM USO AUTOMOTIVO, QUANDO ACIONAVA A BUZINA, APAGAVA O PROGRAMA! RESOLVI COLOCANDO UM INDUTOR E AUMENTEI O VALOR DO CAPACITOR DA ENTRADA!

[fabim]

Tchelo, a uns 4 anos um produto que fiz para um mané aconteceu´só uma vez quando ele fez gambi e ligava o menino com adaptation no tumovi dele.
Ele regravou colocou e foi embora, algumas semanas depois o mesmo aconticeu..

Ele me ligou para perguntar o que podia esta haverndo.
Pedi para ele fazer uma bateria de exames anotar tudo e me mandar.

Estava vindo tensões altas de sparks por tempo relativo e acontecendo realimentação pelos pinos para os periféricos que tinham fios compridos.
Ele chegou a medir picos de 4mS e 28V com o osciloscopio flutuando ao gnd local. Ele mediu entre terra proximo ao pic e MCLR, esse ele pegou vários picos de 16V ..20 e la vai lasca.
Depois de observar tudim, projetei um filtrinho simples com um thyristor de 14V Tresp<25nS e um cap cerâmico de 100nF por 16V em paralelo, este arranjo ficou em dois pontos do circuito..

Depois de colocado os arranjos, ele refez a aferição e o EMI tipo spark máximo que ele achou foi de alguns volts maior que os 12V of course.

Conclusão, dependendo do momento que o pic estava operando, o ruido que vinha pelos pinos de DT e CK + MCLR colocavam o pic em Write por 1 ou 2 ciclos e apagava o endereço 0xvai_saber_qual.

Com toda certeza seu mané, o seu problema é exatamente este..

Lembra do GPRS..... pifava, mais como ? colocou o xingling resolveu. O zener não atuava pois os skarps de crista mais autas eram coisa de alguns uS e vai saber se eram positiva ou negativa, aí o zenin não dava ne ?

Braços

Fabim

[RobL]

Resumindo, isso aí se chama latchup.
Trata-se de condução através do substrado do cmos por ruptura. Quase sempre, no caso dos Pics não danifica, mas estressa.
Neste caso não é necessário que o ruído de alta tensão, produza um protocolo de gravação, para corromper a flash, pois, sua carga (da flash) escapa para "todo lado" através do substrado do cmos. Em fim, programa alterado ou totalmente apagado (descarregado).
Isto pode ocorrer através de qualquer pino, conforme narrado nos posts acima.