You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
\item Aplicația a fost încărcată cu succes, caz în care acest lucru va fi raportat de Flasher cu următorul mesaj: \textit{ Successfully flashed firmware file app.fw} și bootloader-ul va porni aplicația, iar pe dispozitiv se vor vedea efectele rulării ei.
853
853
\item Dacă Flasher-ul pare că s-a blocat și nu funcționează este posibil ca portul serial indicat prin parametrul \texttt{-p} să fie greșit, iar aplicația trebuie repornită cu portul corect.
854
-
\item Bootloader-ul, de la apăsarea butonului, așteaptă 20 de secunde începerea transferului, dacă acest timp se scurge și pe microcontroller există o aplicație existentă, ea va fi rulată, iar procesul trebuie repornit.
854
+
\item Bootloader-ul, de la apăsarea butonului, așteaptă 25 de secunde începerea transferului, dacă acest timp se scurge și pe microcontroller există o aplicație existentă, ea va fi rulată, iar procesul trebuie repornit.
855
855
\item Procesul a eșuat, posibil pentru că aplicația a fost modificată și tag-ul de autentificare nu se potrivește cu cel corect. Flasher-ul va raporta acest caz prin mesajul: \textit{*ERR* Failed to flash firmware file app.fw}, iar procesul trebuie repornit. Dacă situația se repetă există posibilitatea ca fișierul firmware să fi fost modificat în timpul descărcării de la dezvoltator și o re-descărcare poate rezolva problema. De asemenea acest scenariu poate fi cauzat de criptarea aplicației cu o cheie de criptare greșită, caz în care trebuie contactat dezvoltatorul aplicației.
856
856
\end{enumerate}
857
857
858
858
\section{Protocolul de comunicație serială}
859
-
TODO: relativ simplu, transmite doar un fisier nu si chei de criptare
860
-
TODO: protocolul folosit de bootloader-flasher (diagrame de mesaje)
861
-
TODO: vezi emailuri + notitele din caiet
859
+
860
+
Pentru ca Flasher-ul să poată trimite fișierul firmware spre bootloader, trebuie să implementăm un protocol special de comunicație. Evident acest protocol va fi folosit atât de bootloader cât și de Flasher. Protocolul va fi definit prin structura unui pachet și mecanismele care fac posibilă înțelegerea semnificației acestor pachete.
861
+
862
+
Așadar structura unui pachet trimis între Flasher și bootloader este definită în tabelul \ref{protoStruct}.
\multirow{4}{*}{Antet} & \texttt{0x00} & ID (fixat la 0xA5A5) & 2 \\ \cline{2-4}
869
+
& \texttt{0x02} & Tip pachet & 1 \\ \cline{2-4}
870
+
& \texttt{0x03} & Lungime & 1 \\ \hline
871
+
Date & \texttt{0x04} & Conținut pachet & variabil \\ \hline
872
+
CRC & - & Cod polinomial & 2 \\ \hline
873
+
\end{tabular}
874
+
\centering
875
+
\caption{Structura unui pachet al protocolului de comunicație}
876
+
\label{protoStruct}
877
+
\end{table}
878
+
879
+
Observăm în acest tabel faptul că pachetul începe cu un identificator care nu se modifică pe parcursul transmisiei, motivul pentru care am ales acest identificator, este că are biții foarte variați (\texttt{1010 0101 1010 0101}), modificarea unuia singur datorită interferențelor duce la modificarea valorii acestui câmp și deci la invalidarea pachetului. Valoarea aceasta a fost aleasă similar cu valoarea semnăturii unui disc bootabil, motivele fiind similare: dacă acești biți sunt modificați există șanse mari ca și restul biților să fie corupți.
880
+
881
+
Următorul câmp indică tipul pachetului, care poate fi de 4 tipuri:
882
+
\begin{enumerate}
883
+
\item\textbf{FIRST\_PACKET}: Primul pachet. Trimis de la Flasher spre bootloader. După acest tip de pachet va urma în mod sigur (cu excepția cazului de eroare) un pachet de tipul \texttt{NEXT\_PACKET}.
884
+
\item\textbf{NEXT\_PACKET}: Reprezintă un pachet intermediar, nici primul, nici ultimul. Aceste pachete variază la număr în funcție de mărimea aplicației utilizator.
885
+
\item\textbf{LAST\_PACKET}: Ultimul pachet. Trimis de la Flasher spre bootloader. Acest tip de pachet urmează cel mai frecvent după \texttt{NEXT\_PACKET} și este cu siguranță ultimul pachet pe care bootloader-ul îl va primi de la Flasher.
886
+
\item\textbf{STATUS\_PACKET}: Singurul pachet pe care bootloader-ul îl poate trimite. Acesta reprezintă statusul transmisiunii fișierului firmware până la un moment dat.
887
+
\end{enumerate}
888
+
889
+
Câmpul de lungime al pachetului indică numărul de octeți din partea de date a acestuia. Deși lungimea poate varia între 1 octet și 255 de octeți ea este limitată în mod artificial între 1 octet și 240 de octeți. Motivul acestei limitări a fost expus și în motivarea câmpului de padding în cadrul fișierului \texttt{.fw}. Din punct de vedere practic, algoritmul AES, folosit în modul flux, trebuie să primească doar date cu lungimi multiplu de 16 octeți. Se observă ușor că \(240 \% 16 = 0\) și că 240 este cel mai mare multiplu de 16, mai mic decât 255. Această limitare impune o simplificare a bootloader-ului, în sensul în care acesta poate decripta în mod direct orice pachet, el respectând cerințele algoritmului AES. În caz contrar ar fi fost necesar un buffer suplimentar unde am fi acumulat date până când lungimea lor ar fi satisfăcut cerințele algoritmului de decriptare: lungimea să fie multiplu de 16.
890
+
În general pachetele vor transporta lungimea maximă de date criptate pentru a nu irosi putere de procesare și timp de transmisie. Un caz special este primul pachet (\texttt{FIRST\_PACKET}), care nu conține doar date criptate (aplicația utilizator), ci și un antet (conform formatului firmware-ului). Din fericire, am provăzut acest antet cu un câmp de padding, care îl face să ocupe o dimensiune multiplă de 16, iar datele criptate din restul pachetului să își păstreze și ele această dimensiune.
891
+
892
+
Excepție de la regula aceasta o face ultimul pachet, care nu este necesar să aibă o lungime anume. Algoritmul AES în modul flux permițând ca ultimul calup de date procesat să nu mai respecte cerința impusă șiruri de date anterioare. De asemenea, tot excepție de la regulă fac și toate pachetele de tip \texttt{STATUS\_PACKET}. Aceste pachete transportând în zona lor de date un singur octet care indică starea transmisiei la un moment dat.
893
+
894
+
Posibilele stări sunt:
895
+
\begin{itemize}
896
+
\item\textbf{STATUS\_ACK}: Acknowledge. Indică primirea unui pachet și decriptarea cu succes a datelor transportate de acesta. Acest status este trimis după fiecare pachet.
897
+
\item\textbf{STATUS\_ERROR}: Indică o eroare fatală în sistem și cere oprirea transmisiei. În urma trimiterii acestui status, transmisia este oprită.
898
+
\item\textbf{STATUS\_RETRY}: Indică faptul că un pachet nu a fost primit la timp sau că un cod polinomial nu poate fi verificat cu succes. Protocolul implementează un mecanism de timeout, acesta așteaptă câte cinci secunde sosirea unui pachet, iar dacă acesta nu sosește trimite de până la 4 ori \texttt{STATUS\_RETRY}. Așadar timeout-ul maxim este de 25 de secunde. Tot acest status este trimis dacă integritatea unui pachet nu poate fi validată de codul polinomial atașat la finalul acestuia. În general Flasher-ul va retrimite pachetul în cauză în urma procesării unui pachet de tip \texttt{STATUS\_PACKET} cu conținutul \texttt{STATUS\_RETRY}.
899
+
\item\textbf{STATUS\_SUCCESS}: Acest status reprezintă finalizarea cu succes a transmisiei firmware-ului. Acest status se trimite doar după validarea (prin tag-ul de autentificare) și scrierea aplicației în memoria flash. Imediat după trimiterea acestui status, bootloader-ul va continua execuția prin predarea controlului aplicației tocmai primită.
900
+
\end{itemize}
901
+
902
+
La finalul pachetului, în urma conținutului acestuia este atașat un cod polinomial pe doi octeți. Așa cum a fost prezentat la capitolul teoretic acest cod ne permite să verificăm integritatea datelor transportate de pachet. În cazul constatării interferențelor pachetul este ignorat, iar bootloader-ul va cere retransmisia acestuia printr-un pachet de tip \texttt{STATUS\_PACKET} cu conținutul \texttt{STATUS\_RETRY}.
903
+
904
+
Este important să precizăm ca Flasher-ul, în urma transmisiei unui pachet de tipurile \texttt{FIRST\_PACKET}, \texttt{NEXT\_PACKET} sau \texttt{LAST\_PACKET}, așteaptă un pachet de tip \texttt{STATUS\_PACKET} înapoi și doar după ce primește un astfel de pachet cu statusul \texttt{STATUS\_ACK} sau \texttt{STATUS\_RETRY} continuă trimiterea.
905
+
906
+
Ilustrativ, am folosit o diagrama a secvențelor (figura \ref{protocol-msd}) de mesaje pentru a arăta simplitatea protocolului. Aceasta simplitate are ca efect un cod simplu și mic ca dimensiune, atât pentru Flasher, dar și mai important: pentru bootloader.
907
+
\begin{figure}[h]
908
+
\centering
909
+
\includegraphics[width=1\textwidth]{protocol}
910
+
\caption{Diagrama de mesaje a protocolului}
911
+
\label{protocol-msd}
912
+
\end{figure}
913
+
914
+
Figura \ref{protocol-msd} prezintă cazul optimist, când toate pachetele sosesc corect din prima încercare, în figură nefiind prezentate pachetele de status: \texttt{STATUS\_RETRY}, \texttt{STATUS\_ERROR}. Aceste două tipuri de pachete sunt prezentate în figura \ref{protocol-msd-timeout}.
\caption{Diagrama de mesaje a protocolului în cazul de timeout}
920
+
\label{protocol-msd-timeout}
921
+
\end{figure}
922
+
923
+
În această figură este reprezentat cazul de timeout al protocolului. În această situație Flasher-ul trimite un pachet care nu ajunge la bootloader, iar acesta încearcă recuperarea sa fără succes. Se observă faptul că după patru pachete de status cu statusul \texttt{STATUS\_RETRY}, se declară eroare la transmisiune prin \texttt{STATUS\_ERROR}. În acest caz utilizatorul ar trebui să repornească procesul ...
924
+
925
+
TODO: spune cum poate fi flasher-ul acum (timout sau sa primeasca raspounsulile)
926
+
927
+
TODO: relativ simplu (nu continua pana nu rezolva cu un pachet), transmite doar un fisier nu si chei de criptare
0 commit comments