Leonardo (32u4): modi per costruirlo programmaticamente

Quando è stato presentato Leonardo, penso, ho letto alcuni articoli sull'essere cauti nel fare alcune cose, che potrebbero far sì che non carichi più nuovi schizzi, quindi bisogna riscrivere il bootloader. Poiché ho intenzione di utilizzare opzioni di risparmio energetico, ad esempio per disabilitare componenti hardware inutilizzati come la porta USB, temo di fare qualcosa di sbagliato.

Una delicatezza di Leonardo che ho trovato finora:

• se gli interrupt sono disabilitati, il caricamento di nuovi schizzi non riesce a meno che non si prema il pulsante Reimposta non appena l'IDE di Arduino mostra "Caricamento in corso ..."

Quali elementi (ad eccezione delle solite considerazioni relative all'hardware come il collegamento di pin configurati in uscita a potenziali fissi) potrebbero danneggiare il controller o richiedere il reflash del Leonardo con un nuovo bootloader?

Se carichi un programma che modifica la velocità del core USB, sarebbe quasi in muratura. Quello che accadrebbe è questo:

1. Accensione, avvio del caricatore di avvio, dispositivo USB elencato su PC.
2. Pochi secondi dopo l'avvio del programma, la velocità del core USB è cambiata, il dispositivo USB scompare dal PC

Il problema qui è che non solo devi premere reset per programmare, dopo il reset devi selezionare rapidamente la giusta porta com e poi caricare prima dell'avvio del programma.

Redbearlab Blend Micro richiede una velocità del core USB da impostare nel programma utente. Nelle loro istruzioni di installazione c'è un passaggio per modificare Arduino main.cpp e aggiungere una sezione per farlo. Se questo passaggio non viene eseguito, si verifica il problema precedente.

Sono riuscito a brickwall un ATMega128RFA1. Il bootloader e il software in esso caricato funzionavano bene. Ma era impossibile cancellare / scrivere la ROM.

Dopo aver verificato cosa è successo, ho scoperto nel foglio dati che alcuni fusibili nel core AVR hanno lo scopo di proteggere la scrittura accidentale sulla ROM. Una specie di miccia di sicurezza.

Non ho mai trovato il bug che scriveva in questi byte (dato che era un programma davvero grande ed eravamo 3 persone coinvolte nella programmazione) ma sì, abbiamo appena fatto esplodere una miccia e perso un MCU a causa di un bug.

Per quanto riguarda il leonardo, potrebbero accadere diverse cose, ma nessuna di queste può murare la tua tavola a meno che tu non salti una di queste micce di protezione.

È possibile, con un codice davvero intelligente , sfruttare il bootloader per sovrascriverlo.

Estratto:

La soluzione è in realtà concettualmente abbastanza semplice. Un bootloader, per sua stessa natura, è progettato per scaricare nuovo firmware sul dispositivo. Pertanto conterrà almeno un'istruzione spm. Poiché il registro di configurazione spm non deve essere scritto più di 4 cicli prima dell'istruzione spm, ciò significa che praticamente si verificano pochissime sequenze: solo sts, spm o out, sequenze spm. Quindi, tutto ciò che serve è trovare la sequenza nella sezione bootloader; imposta i giusti registri e chiamalo.

Tuttavia, si è scoperto che c'era anche un grosso problema. Le istruzioni spm del bootloader autoprogrammante V-USB non sono una piccola routine ordinata, ma sono integrate nel codice principale; quindi chiamarlo causerebbe semplicemente l'arresto anomalo dell'AVR mentre tentava di eseguire il resto del bootloader V-USB.

Brutto, ma di nuovo c'è una soluzione. Usando un timer con clock alla frequenza della CPU (che è facile su un AVR), è possibile creare una routine in assemblatore che imposta i registri per la sequenza spm di Bootloader; lo chiama e proprio nel momento in cui viene eseguito il primo ciclo dello spm stesso, l'interrupt del timer si spegne e l'AVR dovrebbe passare alla routine di interrupt (nello spazio Applicazione). La routine di interruzione apre l'indirizzo del bootloader e quindi ritorna al codice precedente, che è la routine che imposta la sequenza out, spm. Questo dovrebbe funzionare, perché quando si applicano le istruzioni spm alla sezione bootloader la CPU viene arrestata fino al completamento.

Quindi, fondamentalmente, puoi fare qualche programmazione stravagante, e far fare il bootloader al bootloader, rendendo la MCU inutile senza un programmatore dedicato.

Quello che conosco è fare in modo che Leonard si comporti come un mouse USB che si agita ovunque e digita chiavi casuali in modo da non poterlo riprogrammare senza fare qualche trucco per aggirarlo. Ma lo menzionano nei documenti API.