Ecco la risposta ATMEL:
Dear customer,
Here are some suggests about your issue:
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.
If the bootloader affects USART, please add bootloader code step by step and check which part affects USART
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.