programmare il 644 ... ma come????

Ricordavo bene allora che c'era un problema ma non ricordavo che lo avesse Michele....Appena passa di quì vediamo se posso tornargli utile.
Il 1284 non me lo hanno dato disponibile quindi non posso fare prove anche con quello,dovrei vedere "sotto casa" se ne hanno ma la vedo dura.

Intanto io sto usando la 1.0.1.
All'inizio ho fatto prove con CP2100, MCP2200, FT232RL e 8u2, i risultati sono riportati qui. Quindi l'unico modo che ho io per programmare il 644P è usare il filtro o un partitore sulla linea rx del micro, eccetto il CP2102 che funziona direttamente; invece nessuno di essi va con il 1284P né con filtro e né senza.

Ciao Michele,anche io uso l'ide 1.0.1 ed ho usato l'MCP come convertitore ma,avendo fatte le prove come rimasti qualche post fa,devo dire che non mi ha dato particolari problemi se non dovuti al condensatore in serie al reset che,una volta bypassato,mi ha permesso di caricare sckecth senza l'ausilio di filtri RC sul RX del 644.

Ho ordinato questa mattina il 1284p,dovrebbe arrivare mercoledì/giovedì,appena arriva faccio due prove anche io su quello e vi dico.
Ciao.

Purtroppo ho altre dieci cose da fare nel pochissimo tempo che ho disponibile per il lab; ora non può che venirmi il dubbio che sia il portatile, perché qui secondo me è una frazione di qualcosa....
Il fatto è che altri sul Forum Internazionale sono nelle mie stesse condizioni, la cosa che mi toglie voglia di insistere è il fatto di non aver MAI visto funzionare un 1284P.
Comunque ho fatto una piccola ma dettagliata relazione all'Assistenza ATMEL, inviando loro materiale per fare le prove ed il link al Topic del F.I. in modo che vedano che non sono un visionario e che comunque, anche chi va meglio (v. Leo) è costretto a ricorrere al filtro RC. Sarebbe ora interessante vedere la tua prova col 1284P, se e quando ti arriva. Una sola info: il tuo convertitore MCP2200 lo hai realizzato sul mio schema o hai apportato modifiche particolari? Nella versione che ho dato alla Rivista ho messo il C in serie al DTR (RTS in realtà....) però ho previsto anche un jumper a saldare, in parallelo ad esso per bypassarlo in situazioni come questa.

Per ora le prove le ho fatte tutte con il fisso.
MIke, hai provato a dare alimentazione all'Atmega1284P separatamente e non attraverso il convertitore (e quindi il portatile)?

leo72:
Per ora le prove le ho fatte tutte con il fisso.
MIke, hai provato a dare alimentazione all'Atmega1284P separatamente e non attraverso il convertitore (e quindi il portatile)?

sì, lo leggi qualche post addietro, quella sera che ho poi messo una pull-down sul tx del micro ed a quel punto ho iniziato a vedere attività di risposta, invece dei soliti 3 lampeggi a vuoto, ma comunque ottenendo lo stesso errore. MI era venuto il dubbio dei livelli ed ho provato ad alimentare il micro separatamente da 4,5 a 5,5V mentre il convertitore era alimentato dall'USB, ovviamente masse in comune

Sarebbe ora interessante vedere la tua prova col 1284P, se e quando ti arriva. Una sola info: il tuo convertitore MCP2200 lo hai realizzato sul mio schema o hai apportato modifiche particolari? Nella versione che ho dato alla Rivista ho messo il C in serie al DTR (RTS in realtà....) però ho previsto anche un jumper a saldare, in parallelo ad esso per bypassarlo in situazioni come questa.

Ma,l'ho ordinato questa mattina tramite un amico che ha un negozio di comp,aveva da chiudere un ordine ad RS e gli ha infilato il mio chip,comunque spero mi arrivi presto. Per quanto riguarda l,MCP2200 ho fatto una nuova scheda dove posso sia ponticellare il condensatore con un jumper che la resistenza da 1K (famosa)che in alcune situazioni particolari poteva dare fastidio ma lo schema è lo stesso tuo.
Le prove che ho fatto io sul 644 sono state fatte da portatile e non da fisso.
Ora a parte tutto non entro troppo in merito all'architettura di un micro in quanto sono ignorante ma se è prevista la programmazione seriale è giusto che essa debba funzionare e visto che così non è il problema lo hanno loro (atmel) e dovrebbero a mio parere risolverlo o quanto meno trovare una soluzione che sia sempre funzionale.

il tecnico con cui sono in contatto finora è stato gentile e disponibile, vediamo ora che siamo al nocciolo della questione.....
i miei MCP2200 ora sono in Rivista perché sul numero di febbraio esce l'articolo, quando rientrano posso fare la prova a bypassare le due R da 1K ed eliminare la pull-up sull'rx dell'MCP, intanto aspetto le tue prove.

Va bene..

Ecco la risposta ATMEL:

Dear customer,

Here are some suggests about your issue:

  1. When you program bootloader and USART firmware to the chip, please make sure which entrance (application or bootloader) the firmware runs from when power on.

  2. If the bootloader affects USART, please add bootloader code step by step and check which part affects USART

  3. I soppose RC filter doesn't affect USART communication, please measure the wave of TXD and RXD with oscilloscope to check if they are nomal

Hope this will help you to solve the problem.

Quindi loro pensano che il problema sia nel bootloader, e d'altra parte se io carico via ISP un firmware che gestisce la seriale non ho alcun problema. Secondo loro il filtro non influisce sulla programmazione ed io sono d'accordo e l'ho sempre detto: penso che quei due componenti non svolgano funzione di filtro, visto che deformano l'onda, ma servano o per ritardare l'invio del segnale di TX rispetto all'azione del bootloader o per abbassare la soglia del segnale; in quest'ultimo caso l'ha prova ve l'ho fornita; io che sono costretto ad usare il "filtro" anche col 644, ho provato a sostituire il C con una R, creando di fatto un partitore che diminuiva di circa 1V il segnale, lasciandolo però perfettamente quadro, e a me la programmazione ha funzionato comunque. Purtroppo col 1284 nel mio caso non c'è niente da fare.
La cosa interessante, se ho ben capito il punto 1 è questa: se analizziamo il comportamento tipo del bl, vediamo che quanto il programmatore inizia la sua attività, per prima cosa manda un RESET, in seguito ad esso il bl verifica se c’è attività sulla seriale, altrimenti va ad eseguire l’eventuale firmware. A me pare di aver notato che normalmente l’interrogazione della seriale avvenga ad opera del micro con l’invio di un segnale mediante il proprio TX, al quale il convertitore risponde, e quindi inizia il dialogo; quindi (magari se qualcuno può fare una prova al volo anche col solo Arduino me lo conferma) dopo il reset c’è prima un impulso sul LED tx (se parliamo di Arduino, rx se parliamo di un convertitore esterno) e poi la risposta con l’altro LED. Nel mio caso questo impulso di richiesta NON C’È quindi potrebbero aver ragione loro che il bl non sia in esecuzione o sia troppo in ritardo. Come suggeriscono loro, è possibile seguire passo-passo cosa succede nel bl e provare ad introdurre dei ritardi alla sua esecuzione, dopo l’arrivo del RESET al micro. Ho sempre detto che secondo me il convertitore parte troppo presto rispetto al reset. Insomma sono idee buttate, la verità è che dovremmo metterci in due: uno fa le prove col DSO e l’altro analizza parallelamente il comportamento del sw, ma purtroppo ciò non è possibile, allora chiedo: è possibile, “leggendo” il bootloader, scrivere la sequenza delle operazioni che esso compie nella fase iniziale, comprese ‘uso dell’USART0? Questo mi potrebbe aiutare ad analizzare col DSO il comportamento del micro, e secondo me alla fine ce la facciamo.

Gli do un'occhiata.

ottimo XD

Operazioni eseguite dal main del file optiboot.c (versione 4.5 di maniacbug):

  1. resetta un paio di registri
  2. controlla se il reset è avvenuto per cause esterne (quindi reset per alimentazione assente). In questo caso il chip è stato avviato per la prima volta e viene eseguito lo sketch, saltando il bootloader. Ciò è confermato dal fatto che nel momento in cui si da alimentazione al 1284P, il led sul pin 2 non lampeggia ma lampeggia solo alle successive pressioni del pulsantino di reset
  3. se deve far lampeggiare il led, imposta il timer 1 con prescale /1024 (verrà usato come fonte di tempo)
  4. se non è definito il flag SOFT_UART, imposta la modalità DOUBLE SPEED per la seriale (la SOFT UART è descritta nell'Application Note AVR305 di Atmel, ma non è il nostro caso).
  5. imposta il watchdog per triggerare dopo 500 ms (anche se il valore scelto in realtà direbbe 1s... boh..)
  6. imposta il pin del led come output
  7. se si usa la SOFT UART, imposta TX come output
    8 ) se deve far lampeggiare il led, esegue i lampeggi di saluto
  8. ora entra in un ciclo infinito:
    9.a) preleva un carattere dalla seriale
    9.b) controlla se è il comando di lettura versione (STK_GET_PARAMETER): nel caso spedisce indietro la versione dell'Optiboot
    9.c) controlla se è il comando di SET DEVICE (STK_SET_DEVICE): nel caso lo ignora
    9.d) controlla se è il comando di SET DEVICE EXT (STK_SET_DEVICE_EXT): nel caso lo ignora
    9.e) controlla se è il comando di LOAD ADDRESS (STK_LOAD_ADDRESS): nel caso carica il nuovo indirizzo
    9.f) controlla se è il comando di UNIVERSAL (STK_UNIVERSAL): nel caso lo ignora
    9.g) controlla se è il comando di SCRITTURA SU FLASH (STK_PROG_PAGE): qui entra in una funzione che carica i dati e poi li scrive nella pagina indicata
    9.h) controlla se è il comando di LETTURA DA FLASH (STK_READ_PAGE): qui entra in una funzione che legge la pagina indicata e la spedisce indietro
    9.i) controlla se è il comando di LETTURA SIGNATURE (STK_READ_SIGN): qui entra in una funzione che legge la firma e la rispedisce indietro
    9.j) controlla se è il comando di USCITA DALLA PROGRAMMAZIONE (STK_LEAVE_PROGMODE): setta il watchdog per 16 ms per far resettare il micro
    9.k) per tutti gli altri comandi, risponde un generico "OK" non considerando ciò che riceve

Gran bel lavoro Leo, ora però mi dovresti aiutare nell'interpretazione. Quali sono i passaggi che esegue il bl quando:
1 - micro collegato al Convertitore, collego la porta USB e dò alimentazione (ti confermo che non c'è reset)
2 - apro uno sketch sull'IDE e lo invio al micro (ti confermo che questa operazione inizia con un reset)
vedo i lampeggi del LED sul pin 2, a seguire solo tre lampeggi del TX del convertitore (quello collegato all'rx del micro).

Deduco che arrivi l'alimentazione dal convertitore, giusto?
Allora il punto in questione è il (2). Il registro MCUSR del microcontrollore registra la causa del reset.
Se il riavvio è dovuto ad una causa esterna, viene lanciato lo sketch utente. Il primo avvio ricade in questo caso.
Quindi, collegando il convertitore ma non programmando, il bootloader salta al programma senza mettersi in ascolto sulla seriale.

2 - apro uno sketch sull'IDE e lo invio al micro (ti confermo che questa operazione inizia con un reset)
vedo i lampeggi del LED sul pin 2, a seguire solo tre lampeggi del TX del convertitore (quello collegato all'rx del micro).

In questo caso il bootloader continua dal punto 3).
Fa quindi lampeggiare i led, apre la seriale e si mette in ricezione.
Le operazioni che seguono sono in risposta ai comandi che il bootloader riceve da avrdude.

Servono altri dettagli?

Allora il punto in questione è il (2). Il registro MCUSR del microcontrollore registra la causa del reset.
Se il riavvio è dovuto ad una causa esterna, viene lanciato lo sketch utente. Il primo avvio ricade in questo caso.
Quindi, collegando il convertitore ma non programmando, il bootloader salta al programma senza mettersi in ascolto sulla seriale.

Il problema potrebbe essere legato al fatto che non riesce a distinguere la causa del reset e passi sempre e comunque ad eseguire codice utente.
Potrebbe?

Ciao

MauroTec:

Allora il punto in questione è il (2). Il registro MCUSR del microcontrollore registra la causa del reset.
Se il riavvio è dovuto ad una causa esterna, viene lanciato lo sketch utente. Il primo avvio ricade in questo caso.
Quindi, collegando il convertitore ma non programmando, il bootloader salta al programma senza mettersi in ascolto sulla seriale.

Il problema potrebbe essere legato al fatto che non riesce a distinguere la causa del reset e passi sempre e comunque ad eseguire codice utente.
Potrebbe?

Ciao

Non credo. Perché quando l'Atmega8U2 spedisce il segnale di reset al chip, il led di stato lampeggia, segno che il bootloader ha letto correttamente il registro. D'altronde, stiamo parlando dell'Optiboot, è lo stesso montato sull'Atmega328, corretto per poter gestire Flash con dimensioni superiori ai 64 kB.

Sì, in queste prove standard l'alimentazione viene dal convertitore, proveniente dall'USB.
Confermo che quando faccio l'upload il reset avviene perché lampeggia il LED messo sul pin 2 del micro, proprio per tale verifica, cosa che non succede all'accensione.
Vorrei sapere questo: posto che tu trovi riscontro in quello che "racconto" seguendo il tuo schema sequenziale, secondo te, nel momento in cui il micro preleva il primo carattere dalla seriale , non dovrebbe chiederglielo?? cioè non dovrei vedere lampeggiare il LED RX del convertitore, segno che il micro sta chiedendo qualcosa? Come sai scrivo da casa, dove non ho nulla per fare prove, poi tutto ciò che esce dalle discussioni diventa oggetto di prova e verifica. Vorrei che tu verificassi il 644 (che lavora senza filtro da te) per darmi conferma di questa cosa, anche se forse i LED di Arduino sono siglati lato micro e non lato 8u2, verifica tu.
In pratica dopo il lampeggio del LED 2 mi aspetterei un flash del led rx del convertitore, seguito da un flash del led tx, e poi tutta la "discussione" con entrambi che lavorano ininterrottamente.

Michele, te porti male XD
Oggi senza filtro RC non riesco a programmare il mio Atmega644P. ]:smiley:

Vabbè.... andiamo avanti :sweat_smile:

Premetto: mi baso su cosa faccia l'Atmega8U2 perché i led dell'Arduino UNO sono pilotati da questo chip.
Detto questo, il bootloader non chiede i dati sulla seriale, semplicemente si mette in attesa. Se arriva qualcosa, lo interpreta. Altrimenti se non arriva nulla il watchdog provvederà al timeout, cioè all'uscita dopo tot periodo senza nulla con un bel reset. Questo lo verifico perché premendo il reset e resettando l'Atmega644P, il led RX sull'Arduino non lampeggia, segno che il bootloader verso il chip non invia nulla.

Questa è la mia analisi dei dati, attendo ora le tue conclusioni. :wink: