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

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:

Leuccio mio :* non ti farei del male nemmeno se tu fossi l'ultimo ostacolo tra me e la Bellucci (sono sicuro che ti scanseresti di tuo ]:D)
Se ti può consolare ti ricordo che la mia prima vittima sono me stesso 8), quindi non chiedermi che ti succede, ma se non hai dimenticato qualcosa, ciò che ti accade non è altro che la prova dell'inaffidabilità di questa comunicazione....
Conclusioni? secondo ciò che dici tutto va bene ed invece non va bene nulla.
Per cui a questo punto, avendo molto più chiari (grazie a te XD) i meccanismi del dialogo, non mi resta che collegare il DSO, appena sarà possibile..., e fotografare i vari momenti dei pin reset, tx e rx, sia sul 644 che sul 1284, con e senza filtro. Un bel servizio da mandare a mamma ATMEL per farle vedere i sui figlioli quanti capricci fanno, sperando ci capiscano qualcosa, maremma seriale ]:smiley: ]:smiley: ]:smiley:

Manco morto! ]:slight_smile:

Se ti può consolare ti ricordo che la mia prima vittima sono me stesso 8), quindi non chiedermi che ti succede, ma se non hai dimenticato qualcosa, ciò che ti accade non è altro che la prova dell'inaffidabilità di questa comunicazione....
Conclusioni? secondo ciò che dici tutto va bene ed invece non va bene nulla.
Per cui a questo punto, avendo molto più chiari (grazie a te XD) i meccanismi del dialogo, non mi resta che collegare il DSO, appena sarà possibile..., e fotografare i vari momenti dei pin reset, tx e rx, sia sul 644 che sul 1284, con e senza filtro. Un bel servizio da mandare a mamma ATMEL per farle vedere i sui figlioli quanti capricci fanno, sperando ci capiscano qualcosa, maremma seriale ]:smiley: ]:smiley: ]:smiley:

Ho deciso, per il mio compleanno mi compro un DSO anch'io... mi sento troppo limitato senza :sweat_smile:

Sarebbe ora! fatti consigliare da Astro :wink: ti aggiorno appeno potrò fare prove :slight_smile:

A me andrebbe bene un DSO come il tuo, non pretendo strumenti professionali: 1) non saprei come usarli, 2) la moglie mi rincorrerebbe :stuck_out_tongue_closed_eyes:

leo72:

[quote author=Michele Menniti link=topic=136740.msg1085758#msg1085758 date=1358978077]
Sarebbe ora! fatti consigliare da Astro :wink: ti aggiorno appeno potrò fare prove :slight_smile:

A me andrebbe bene un DSO come il tuo, non pretendo strumenti professionali: 1) non saprei come usarli, 2) la moglie mi rincorrerebbe :stuck_out_tongue_closed_eyes:
[/quote]
:fearful: GW-INSTEK GDS2064

:fearful: GW-INSTEK GDS2064
[/quote]

Leo, questo lo compri per te e a tua moglie il Bimby --> http://bimby.vorwerk.it/it/home/ :wink:
Il prezzo è il medesimo. :astonished:

@Mike:
in quel prezzo c'è uno zero di troppo $)
:stuck_out_tongue_closed_eyes: :stuck_out_tongue_closed_eyes:

@paolo:
non se ne parla nemmeno :stuck_out_tongue:

Oggi ho ritirato il 1284 ed ho fatto adesso qualche prova sulla seriale usando l'mcp2200 come convertitore.
Mettendo RC ,che più che un filtro è più una rete di ritardo sul rx del 1284 carico senza problemi gli scketch in seriale,se invece non metto nulla non si trova in sincronia con il programmatore.
@Michele
ti do ragione sul fatto che il convertitore parte troppo presto con i dati da inviare al 1284,l'anticipo del segnale è di qualche microsecondo e lo si nota sovrapponendo i segnali ottenuti prima e dopo la rete di ritardo.

Per riuscire a programmare entrambi i micro 644/1280 basta mettere in serie al pin rx una R di 120K ed eliminare il condensatore,ho fatto diverse prove con entrambi i micro e nel mio caso il problema non si presenta.

tonid:
Oggi ho ritirato il 1284 ed ho fatto adesso qualche prova sulla seriale usando l'mcp2200 come convertitore.
Mettendo RC ,che più che un filtro è più una rete di ritardo sul rx del 1284 carico senza problemi gli scketch in seriale,se invece non metto nulla non si trova in sincronia con il programmatore.
@Michele
ti do ragione sul fatto che il convertitore parte troppo presto con i dati da inviare al 1284,l'anticipo del segnale è di qualche microsecondo e lo si nota sovrapponendo i segnali ottenuti prima e dopo la rete di ritardo.

Ti ricordo che il bootloader è lo stesso Optiboot dell'Atmega328 solo modificato per poter gestire il 3° registro indirizzi che serve a programmare memorie più grandi di 64 kB (limite dei registri a 16 bit).
Per curiosità, potresti analizzare anche i tempi di risposta di un Atmega328 con Optiboot per capire se è il micro che è più rapido del 1284 oppure se la modifica SW influisce sui tempi di risposta del bootloader?
Altra cosa, a te ha influito la lunghezza del collegamento? A me sì. Nel senso che se anche uso la rete RC (chiamiamola così visto che non è un filtro, quindi) se antempongo un jumper troppo lungo il chip non risponde correttamente.

Per riuscire a programmare entrambi i micro 644/1280 basta mettere in serie al pin rx una R di 120K ed eliminare il condensatore,ho fatto diverse prove con entrambi i micro e nel mio caso il problema non si presenta.

Domani provo questa configurazione.