Estou tentando gravar um programa no Arduino Mega ch340, porém não consigo gravar.

Já tentei compilar outros programas pra ele, como o blink, e alguns outros que tenho feito aqui, e todos completam, menos esse programa.

Já procurei no google sobre o problema, e vi gente falando pra não abrir pelo arquivo .ino que ia dar certo, abrir pela IDE do Arduino, e já fiz isso, mas não resolveu.

Também já coloquei o programa para executar como administrador, que também vi na internet que seria o problema, mas sem solução também.

E engraçado que compilo pro Arduino Uno, e funciona normalmente o programa, só no Mega que acontece esse problema.

Se alguém souber se tem solução, ficaria grato!

Segue em anexo o programa, e um txt com as mensagens de saída de compilação e de carregamento.

Aparece o erro a seguir:


O sketch usa 13606 bytes (5%) de espaço de armazenamento para programas. O máximo são 253952 bytes.
Variáveis globais usam 586 bytes (7%) de memória dinâmica, deixando 7606 bytes para variáveis locais. O máximo são 8192 bytes.
Ocorreu um erro enquanto o sketch era carregado

Exibições: 838

Anexos

Responder esta

Respostas a este tópico

Boa tarde Murilo, 

Tem certeza que o chip de interface USB/Serial do seu Arduino Mega é o CH340? 

Se for, instale esse driver, antes de conectar a placa. 

https://learn.sparkfun.com/tutorials/how-to-install-ch340-drivers/all

Se ainda tiver dificuldade, sugiro a leitura do meu tutorial :

Guia completo do ARDUINO MEGA

https://blog.eletrogate.com/guia-completo-do-arduino-mega/

Suspeite do cabo USB! Troque-o também. 

Boa tarde MSZ,

Carreguei seu sketch no UNO e em um mini, e não tive problemas.

Mas não consegui carregar no Mega.

Tem algum problema com a biblioteca RtcDS3231.h.

pois ao gravar seu sketch em 2 Megas diferentes, eles "travaram" durante o upload.

Estou reduzindo ao máximo o sketch, mas ainda estou tendo travamento

Informarei aqui se descobrir a razão deste travamento.

RV

Estou testando esta biblioteca com este sketch.

E ao carregar trava o upload, ficando sempre " uploading".

Então fecho a IDE e abro novamente, ao abrir a serial qdo compilado com Serial.begin de 9600

fica impresso assim:

⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮⸮
Relógio !!

Se mudo pra 115200 fica impresso assim:

tloader>' Huh?
Bootloader⸮⸮⸮

TesteMega.ino

Se outro amigo aqui tiver um Mega e puder fazer um teste serial legal.

RV

Depois de muito pesquisar, descobri o problema!

Nas linhas para imprimir no serial monitor, tem a frase: 

Serial.println("Relógio está desatualizado!!!");

É só tirar as !, que o problema é resolvido.

Não sei bem o porque do problema, mas acontece apenas com o arduino mega.

Tenta fazer o teste aí.

Retire as ! das seguintes linhas:

25. Serial.println("Relógio está desatualizado.");

48. Serial.println("Relógio está desatualizado.");

Bom dia MSZ,

eu já tinha feito um teste com somente 3 linhas e dava erro qdo usava 3 sinais de !,

e não dava qdo usava somente dois sinais de !.

Testei este sketch com 2 megas diferentes.

O Mega original, que usa o Atmega 8U2 como USB/TTL, dá erro, o mega que não é

original e usa um CH340G como USB/TTL, não dá erro.

Ainda estou pesquisando a razão desta "loucura".

Exemplo super simplificado que estou usando.

TesteMega.ino

RV

olá grande RV.

      Veja o motivo da "loucura",  conforme descrevo no post a seguir.

      Estou te devendo alguns "reports". Não me esqueci.

      Abrçs,

      Elcids

Boa tarde Sr. EC,

obrigado pela ajuda, realmente " living and learning", 

Quanto aos "reports",, be cool.

Depois do comentário do amigo MRZ, informando sobre o problema com os 3 sinais de

exclamação, fui pesquisar e descobri um post de um cara em 2012.

E confirma sua descrição, segue abaixo a tradução do texto do cara.

RV

"

Sim, é um bug conhecido no programa mega bootloader (onde se um fluxo de dados de upload tiver três caracteres! Consecutivos (e que podem ser strings constantes ou valores de char em seu esboço, ou apenas três valores de byte equivalentes é a parte do código do enviar o esboço) que faz com que o bootloader pule para um 'modo monitor' aguardando os comandos do monitor do usuário (que nunca virão), interrompendo a operação de carregamento.

Outro bug conhecido do megadoadloader é que ele não lida com interrupções do cronômetro de vigilância corretos como corrigiram no bootloader do Uno. Há mega bootloaders corrigidos / atualizados disponíveis há algum tempo (não tenho certeza de onde encontrá-los), mas no momento um mega bootloader "fixo" ainda não está sendo fornecido com a mega board, nem o IDE tem um mega bootloader atualizado como parte da distribuição do arduino IDE. Basta colocar o arduino mega não recebeu nenhum amor da empresa arduino por um longo tempo. Este bug existe há pelo menos tanto tempo quanto o original mega1280 começou a ser comercializado há vários anos.

"

Texto original

"

Yes, it's a known bug in the mega bootloader program (where if an upload data stream has three consecutive ! characters (and that can either be constant string or char values in your sketch, or just three equivalent byte values is the code part of the uploading the sketch) that causes the bootloader to jump into a 'monitor mode' awaiting user monitor commands (which will never come) thus hanging the up load operation. The other known mega bootloader bug is that it doesn't handle watch dog timer interrupts correct as they did fix in the Uno's bootloader. There has been corrected/updated mega bootloaders available for some time now (not sure where to find it though) but at present a 'fixed' mega bootloader is still not shipping with mega board, nor does the IDE have a updated mega bootloader as part of the arduino IDE distribution. Simply put the arduino mega just has received no love from the arduino company for a long while now. This bug has existed for at least as long as the original mega1280 started shipping several years ago.

"

olá Murilo.

      Parece que alguma "figurinha" (lá na China provavelmente), está compilando e gravando o Bootloader do Mega,  com o "Monitor" habilitado. Ou seja, o Bootloader foi compilado e gravado em Fábrica  com a possibilidade de se usar o "Modo Monitor", caso isto seja requerido via "comando" recebido via Serial.

      E adivinha como o Bootloader detecta que vc quer usar o "Modo Monitor" ?

      Ele simplesmente fica "trilhando" os caracteres recebidos via Serial, à procura de justamente três "!" ( três pontos de exclamação) consecutivamente enviados via Serial (apenas quando o Bootloader está executando).  Assim, se durante o carregamento do seu código, isto for detectado, ele inicia o "Modo Monitor", e aí o carregamento propriamente dito do código, não prosseguirá.

      Você pode ver isso ocorrendo no código do Bootloader para o Mega, conforme evidencio na figura a seguir:

(clique na figura para "zoom")

      Claro,  pode ser que todos os Bootloaders do Mega,  gravados de Fábrica, estejam "saindo" com a opção do "Modo Monitor" habilitado (afinal o Mega tem muita Memória Flash, e o código a mais do Monitor  não representará nenhuma penalidade). Na sua placa Murilo, e na do RV, certamente está assim.  Muito provavelmente a minha aqui também está (mas eu não tive curiosidade de fazer o teste dos três "!" pra saber).

      Então qual a dica?  provavelmente removendo um dos três "!", impedirá a detecção. Ou então coloque espaços estre os "!", caso vc realmente precise "levantar a voz".

      Espero ter ajudado,

      Abrçs,

      Elcids

Opa, parece que vc acertou na mosca, Elcids. 

Mais uma vez..

Valeu pela explicação! Show de bola.

Demorei pra encontrar o problema, mas agora estou ciente para futuros programas.

olá RV.

      De fato eu imaginava que algumas pessoas mundo afora já tinham "topado" com esta questão dos três "!". Isso porque isto está evidenciado logo no início do código do Bootloader do Mega, conforme vc pode ver na figura a seguir:

(clique na figura para "zoom")

      Observe que em novembro de 2010, "quem" mexia com Bootloader na época,  tinha feito uma correção para tratar o problema.  Mas então vem a questão:  se já mexeram nisso (e já faz bastante tempo),  como então ainda ocorre.  A resposta pra isso, certamente está nos #define acrescentados no código pra "corrigir" o problema.  É quase certo que antes da correção,  não haviam os "#define" que permitiam desabilitar o "Modo Monitor", e aí a coisa era pior.  Então a dita "correção" foi acrescentar os #define, e documentar isso.  Assim para não usar o "Modo Monitor", basta ir lá no código do Bootloader e comentar  a linha que habilita o mesmo. Esta linha é a que mostro na figura a seguir:

(clique na figura para "zoom")

      Ocorre no entanto,  que a chinesada  não está fazendo isso,  e quando gravam o Bootloader no Mega, estão gravando uma versão que foi compilada sem comentar a linha mostrada na figura anterior.

      Conclusão:  "resolveram" o problema, mas não eliminaram ele completamente, já que se não for comentada aquela linha no código,  vai continuar exatamente do mesmo jeito.

      Em minha opinião, até poderiam deixar o "Modo Monitor" habilitado, mas deveriam ter feito uma forma mais segura de entrar nele, como por exemplo detectando uma sequência improvável de 6 caracteres ou então uma mensagem também improvável.  Ou seja,  atualmente, a "senha" pra entrar no "Modo Monitor" é daquelas que o povo classifica como "fraca",  e aí deu no que deu.

      E o maior problema disso,  não é quando colocamos strings ASCII no código,  pois veja vc que neste caso,  aplicando técnicas corretas de depuração (que certamente foi o que o Murilo fez),  as pessoas ainda poderão "descobrir" e contornar o problema, ainda que com algum sofrimento.  O maior problema é se por uma coincidência,  o código Assembly resultar em ter em qualquer lugar,  a sequência  de três bytes 0x21 (código ASCII do "!"). Aí a coisa fica feia,  pois como é que alguém vai desconfiar disso?  Neste caso, mesmo que a pessoa conheça técnicas de depuração sofisticadas,  também vai precisar de uma sorte imensa pra descobrir o problema (nem imagino o quanto de sorte).

      Veja na figura a seguir a localização dos três "!" no HEX  do seu segundo código "TesteMega.ino" (o menor deles):

(clique na figura para "zoom")

      Mas se vc alterar este HEX, acrescentando a sequência em qualquer lugar nele (e claro, ajustando o CheckSum do HEX de acordo),  o problema vai ocorrer da mesma forma.

      E se existir a possibilidade de no Assembly do AVR, aparecer alguma instrução que gere a sequencia de três 0x21,  a coisa vai acontecer.  Numa análise superficial,  a resposta seria sim. Imagine que uma instrução qualquer acesse a Memória no endereço 0x2121 com um operando apontado via "Endereçamento Imediato" do valor 0x21.  Então já viu né?  Iria dar zica,  e daquelas.  Mas eu fiz uma análise das instruções do AVR,  e  felizmente não encontrei essa possibilidade (ufa!).  Mas isso não resolve o problema, pois nada vai impedir que a sequência apareça de uma outra origem qualquer.  Então o melhor seria que o "Modo Monitor" estivesse de fato desabilitado no Mega,  afinal,  quem utiliza este modo?  E se alguém fizer uso disto, poderá gravar uma versão com ele habilitado,  já que esse uso é pra condições muito específicas.

      Abrçs,

      Elcids

RSS

© 2024   Criado por Marcelo Rodrigues.   Ativado por

Badges  |  Relatar um incidente  |  Termos de serviço