ASM51

Compro componentes baratos, via Ebay.
Penso que muitos deles não devem ser originais, por isso, só os uso quando o projeto não exige que o mesmo funcione em seus limites.
Estou fazendo um temporizador, apesar de já possuir um com LCD. O diferencial veio da necessidade de precisar, que o temporizador acione uma carga com um tempo determinado. Além disso, gostaria acompanhar a contagem regressiva, mas ocorre que o ambiente tem que ficar no escuro, como é o caso de sensibilização de PCI com luz UV.

Diferentemente de meu temporizador comprado, o que está em construção tem que possuir mostrador com leds de 7 seguimentos, para visualizar a contagem no escuro e um relê que ligue e desligue uma carga. Além disso, incluí a contagem de até 99 horas. Acho que exagerei hehehe.

Usei um PIC16F628A e um BCD-7 seg. Até aí tudo bem.
O problema é o seguinte...
Logo após gravar o firmware com o PIC fora do circuito, coloco-o na PCB e ligo. Provisoriamente uso uma fonte regulada comercial.
Ocorre que o funcionamento apresenta alguns desvios de conduta. Ao clicar para iniciar uma contagem regressiva, a contagem não é iniciada e nem o relê é acionado. Mas este problema não é o mesmo sempre que termino de incluir o firmware.
Até aí tudo bem. Uma explicação fácil e simplista é que o firmware não está correto, certo? Errado!!!
Por algum motivo, após desligar a fonte e religá-la, o firmware passa a funcionar corretamente.
Pensei.
- Este problema pode ser aleatório. Vou deixar algumas horas desligado e ligá-lo novamente para ver se o problema reaparece.
Não reaparece! Só ocorre após ligar pela primeira vez depois de nova gravação de firmware.

Para constar, programei em Assembler, já que é um código com menos de 2k bytes.

Pergunto se alguém já observou este problema.

Sou eng. eletrônico atuante há várias décadas e afirmo que a eletrônica é o paraíso para as leis de Murph!!! (Não queria dizer que eletrônica é coisa do Demo!!!!)

MOR_AL

Este tipo de problema é o motivo pelo qual eu não uso uC sem suporte de debug.
Vai saber o que pode ser...

O que esta usando como oscilador principal do PIC?
Seu programa lê algum valor da Eeprom no início?

Eu 2012 eu produzia um bridge de MODBUS para um protocolo proprietário. Ele era bem simples, rodar em um MC9S08AC32 (culpa do Kraft). O software era composto de duas máquinas de estado que compartilhavam dados por meio de filas. Eu utilizava um dos canais do timer para gerar uma interrupção de 1ms que era uma base de tempo interna. Depois de mais de 2 anos produzindo a interface sem maiores problemas, ou seja gravava e funcionava, recebemos um lote de AC32 onde o software não "rodava". Então, prontamente, coloquei o projeto para depurar via BDM e pude ver que não estava gerando a int do canal do timer. Na época, conferi todos os bits e estavam certos, então mudei para outro timer e por transbordo e deixei quieto.
Mas não me conformo até hoje, pois não era pra uma coisa dessas acontecer.

eletroinf escreveu:Este tipo de problema é o motivo pelo qual eu não uso uC sem suporte de debug.
Vai saber o que pode ser...

Estou deixando para resolver este problema mais tarde. Por enquanto deixo ele me incomodar até ficar P#&o e querer acabar com ele.
No momento estou fazendo maquiagem. Acertando os tempos dos tons, etc.

vtrx escreveu:O que esta usando como oscilador principal do PIC?
Seu programa lê algum valor da Eeprom no início?

Uso um cristal de 4MHz e não acesso nada de EEPROM. Ela fica sempre "limpa".

Aquino escreveu:Eu 2012 eu produzia um bridge de MODBUS para um protocolo proprietário. Ele era bem simples, rodar em um MC9S08AC32 (culpa do Kraft). O software era composto de duas máquinas de estado que compartilhavam dados por meio de filas. Eu utilizava um dos canais do timer para gerar uma interrupção de 1ms que era uma base de tempo interna. Depois de mais de 2 anos produzindo a interface sem maiores problemas, ou seja gravava e funcionava, recebemos um lote de AC32 onde o software não "rodava". Então, prontamente, coloquei o projeto para depurar via BDM e pude ver que não estava gerando a int do canal do timer. Na época, conferi todos os bits e estavam certos, então mudei para outro timer e por transbordo e deixei quieto.
Mas não me conformo até hoje, pois não era pra uma coisa dessas acontecer.

Esse temporizador usa o Timer0 como base de tempo de 2,5ms para tudo; a contagem de um segundo, a verificação do teclado, a multiplexação do mostrador, a geração do "bip", quando se tecla alguma tecla válida para o momento e a geração do trem de pulsos informando o final da contagem regressiva. Mas dentro da rotina de interrupção só tem pouca coisa. Ela basicamente altera bits, que são verificados fora dela, no loop principal, a cada menos do tempo do Timer0 (de 2,5ms).

MOR_AL

A pergunta besta padrão: você não tem nenhum conhecido que possa lhe emprestar um 16F628A para tirar a teima se o problema é o seu chip/lote?

Olá Morris,

Já tentou gravar algo mais simples (pisca LED), no mesmo HARDWARE, com os mesmos FUSES?

Está com cara de que há algum tipo de ruído no PIC na hora da alimentação. Talvez esse ruído só aconteça quando o aparelho é gravado (sabe-se lá o porque).

Você colocou capacitores de 100nF entre o VCC e o GND, proximo ao pino de alimentação? Se eles estiverem presentes, adicione mais capacitância, talvez melhore. Cheque as trilhas de VCC/GND e veja se elas não podem ser induzidas por uma fonte de ruído (por exemplo, o relê).

Na maioria das vezes que pequei um uC qualquer dando problemas aleatórios (sem sentido lógico), era problemas de desacoplamento. Os fuses podem ajudar também (coisas como o brownout podem deixar o reset mais estável). Uma implementação de watchdog pode ajudar em alguns casos específicos.

E se quiser atacar o efeito do problema, e não a raiz, dá pra colocar uma flag na EEPROM dizendo se o PIC já foi ligado alguma vez. Se nunca foi, ele pode se resetar.

pamv escreveu:A pergunta besta padrão: você não tem nenhum conhecido que possa lhe emprestar um 16F628A para tirar a teima se o problema é o seu chip/lote?

Eu devo ter um PIC16F628A de outro lote. Boa dica, vou fazer isso. Será o teste #1

RAWeigel escreveu:Olá Morris,

Já tentou gravar algo mais simples (pisca LED), no mesmo HARDWARE, com os mesmos FUSES?

Antes de fazer a "PCI final", eu montei em um conjunto "PCI com o PIC" e Protoboard. Na versão inicial, não tinha observado o problema, porém, como as primeiras versões possuem muitas partes para se corrigir, não reparei neste detalhe.
Vou gravar outro programa do tipo pisca-led com o mesmo hardware e mesmos fuses, para ver o que ocorre. Aliás este será o teste #2

pbernardi escreveu:Está com cara de que há algum tipo de ruído no PIC na hora da alimentação. Talvez esse ruído só aconteça quando o aparelho é gravado (sabe-se lá o porque).

Antes de gravar, leio o PIC para saber se o gravador está lendo. Depois apago o firmware e verifico se está tudo apagado. Depois gravo a nova versão. O processo de gravação é feito pelo ICPROG na condição de ir verificando na medida que for gravando. Ao final recebo a informação de que a gravação foi feita com sucesso.

Você colocou capacitores de 100nF entre o VCC e o GND, proximo ao pino de alimentação? Se eles estiverem presentes, adicione mais capacitância, talvez melhore. Cheque as trilhas de VCC/GND e veja se elas não podem ser induzidas por uma fonte de ruído (por exemplo, o relê).

Já tem diversos capacitores de 100nF. Além dos juntos com os CIs (PIC e BCD-7Seg), tem os na entrada da alimentação das duas placas de CI que compõem o temporizador, além dos dois eletrolíticos, um em cada placa.

Na maioria das vezes que pequei um uC qualquer dando problemas aleatórios (sem sentido lógico), era problemas de desacoplamento. Os fuses podem ajudar também (coisas como o brownout podem deixar o reset mais estável). Uma implementação de watchdog pode ajudar em alguns casos específicos.

Vou incluir o fuse de Power-Up, apesar do problema ocorrer com a mesma fonte comercial, tanto logo após a programação, como depois. Também vou incluir o fuse "Brown-out"

E se quiser atacar o efeito do problema, e não a raiz, dá pra colocar uma flag na EEPROM dizendo se o PIC já foi ligado alguma vez. Se nunca foi, ele pode se resetar.

É uma opção, mas vou incluir esta opção só em caso extremo.

MOR_AL

Sempre configuro manualmente todos os fuses. Está fazendo isso ou omitiu algum?
Fez debug in-circuit?

ÁgioFelipe escreveu:Sempre configuro manualmente todos os fuses. Está fazendo isso ou omitiu algum?
Fez debug in-circuit?

Configuro manualmente os fuses.

Meu pino RA5 está com um resistor de 10k ohms e um capacitor de 1uF. Dá uma constante de tempo de 10ms. Até já pesquisei qual é a tensão que este pino considera high. É 0,8Vdd (4V). O tempo para a tensão em RA5 chegar a 4V é de 16ms. Estando alimentando ainda com uma fonte comercial antecipadamente ligada com 5V, o tempo de carga dos capacitores do circuito é bem inferior a esses 16ms.
Já fiz de tudo, de cabo-a-rabo, mas ainda continua ocorrendo o problema. Já li e comparei com o meu fluxograma cada linha do assembler mais de uma vez, sem conseguir encontrar nada que esteja causando o erro inicial. Já troquei de PIC, já fiz outra programação, já testei cada rotina individual...
Mas às vezes o erro é tão simples, que podemos ler mil vezes e não percebermos nada.
Acho que pode ser isso que esteja acontecendo. Fora a primeira energização após a programação, tudo o mais está funcionando corretamente. Até mesmo quase todas as partes cosméticas.
Como para um processador não existe erro grande ou pequeno, ontem descobri que meu fuse MCRLbarra estava desligado. Vou liga-lo e fazer este último teste, caso continue assim, vou deixar como está mesmo.
Tomara que seja este o problema... Na quinta-feira vou testar mais uma nova versão, com MCRLbarra em ON.
MOR_AL

Já tentou desligar e descarregar todos os capacitores manualmente (curto circuitando-os), se for possível é claro, para ver se o problema volta?

Será que não tem chances de estar ocorrendo interrupções sem tratamento?
Ligar o MCLR pode ser uma boa.

Em todo o caso, esses PICs antigos são famosos por serem fracos contra ruido, será que não vale a pena tentar um mais novo?

edsont escreveu:Já tentou desligar e descarregar todos os capacitores manualmente (curto circuitando-os), se for possível é claro, para ver se o problema volta?

Não! É praticamente impossível fazer isso. São duas placas, uma sobre a outra, mas de um dia para o outro todas as tensões vão a zero. Aliás, já houve ocasião de passar mais de uma semana.

mastk escreveu:Será que não tem chances de estar ocorrendo interrupções sem tratamento?
Ligar o MCLR pode ser uma boa.

Em todo o caso, esses PICs antigos são famosos por serem fracos contra ruido, será que não vale a pena tentar um mais novo?

Todas as interrupções foram desligadas , via programação, antes de iniciar a parte principal. Não deixei o início do programa (ao ligar) fazer isso por mim.

Minha fonte de alimentação provisória ainda é daquelas lineares, comerciais sem chaveamento. Ela fica ligada, estável em +5V, com capacidade de fornecer energia, porém só depois disso é que a conecto no circuito. Não é ruído. O circuito tem capacitores até em excesso, além daquele entre os pinos de Vdd e o terra do PIC.

Como informei, amanhã, quinta-feira, poderei introduzir as alterações nos fuses. Só falta isso ... e tenho quase certeza que o problema está lá.
Quando testar darei um retorno.
Não acredito nisso, mas para mim, que trato com eletrônica há mais de 50 anos (comecei com 14), digo que "Eletrônica é coisa do Demo" Ou praga do Murphy.

MOR_AL

Atualizando...
Quando uma coisa dá errado em um projeto e não conseguimos descobrir o porque, depois de muitas tentativas para solucionar, começamos a desconfiar de falhas externas ao nosso projeto. Foi o que aconteceu aqui. Passei a desconfiar do CI XingLing. Troquei o CI, mas ainda assim o problema continuava.
Como o problema só aparecia logo após gravar o programa e também se mostrou até suportável, passei a considera-lo como um simples inconveniente. Parti para a montagem final na caixa, usando uma fonte XingLing, essa testada previamente com a minha carga eletrônica e além de aprovada, a carga exige apenas 10% da corrente da fonte (100mA máximo).
Mesmo assim ainda não me dava por vencido. Queria descobrir porque tinha que teclar a tecla "Limpa" e "Inicia/Para" diversas vezes, para passar a funcionar sem apresentar defeito algum.
Descobri que a sequência errada dos eventos se mostrava regular. Não era uma sequência aleatória e que ocorria apenas ao se ligar pela primeira vez, logo após gravar o programa.
Peguei o fluxograma do projeto, que é composto por 12 ou 13 páginas, e comecei a esmiuçá-lo. Coloquei quase todas as variáveis relevantes e os bits de controle de fluxo do programa em uma folha de papel e segui a lógica de programação. Desconfiei de tudo. De todas as variáveis e bits de controle. Depois de muitas horas, comecei a reduzir as variáveis e bits da lista, até que duas variáveis, as quais ironicamente nem mesmo faziam parte da lista de suspeitas, me chamaram a atenção. Eram duas variáveis, que integram a contagem do tempo de um segundo. Uma inicia com 200 (byte menos significativo) e a outra com 2 (byte mais significativo). O detalhe é que elas estão determinadas corretamente na rotina, mas ao analisar e seguir a sequência do programa, desconfiei que ambas poderiam iniciar em zero.
Ora! E se elas iniciassem mesmo em zero, o que ocorreria?
O byte menos significativo, ao invés de contar 200, contaria 256 e o byte mais significativo, ao invés de contar apenas 2, contaria 256. Então, o que se esperava contar 2 x 200 = 400, contaria 256 x 256 = 65536, ou quase 134 vezes mais. Isso poderia justificar o problema. Devido a certa e justificável impaciência, pensava que o programa estava travado, mas ele estava contando 134 segundos iniciais. Ao supor que ele estava travado, teclava a tecla "Inicia/Para" e isso cancelava a contagem de 134 segundos, passando a funcionar normalmente.
Como teste para confirmar minhas suspeitas, decidi ligar o aparelho, programar uma contagem regressiva de 5 segundos, teclar a tecla "Inicia/Para" e aguardar, para ver se a contagem regressiva iniciava.....
Tam, tam, tam tam! Suspense..... De repente o contador acionou o relé de carga e a contagem decrescente iniciou.
PQP! Esse deu muito trabalho.

Próximo passo.

Abrir o Contador/Temporizador e reprogramar o PIC com as duas variáveis iniciando em 200 e 2.

Quero aproveitar e me desculpar com os produtos XingLing, pois nem sempre são os vilões dos projetos.

A imagem do aparelho encontra-se no endereço a seguir.

https://drive.google.com/open?id=1mdmKs ... egG-uQ8ZuA

MOR_AL