Când vine vorba de găsirea și remedierea erorilor sau a comportamentelor nedorite în codul aplicațiilor embedded, majoritatea dezvoltatorilor se vor gândi, probabil, în primul rând la depanarea interactivă. În acest proces, dezvoltatorul folosește puncte de întrerupere, ‘stepping’ și supravegherea memoriei pentru a-și face o idee despre modul în care se execută aplicația.
Figura 1: Hardware Tracing. (© iSYSTEM) ▶
Deși acest tip de depanare face parte din rutina zilnică a fiecărui dezvoltator de software, există unele limitări inerente, în special atunci când avem de-a face cu sisteme embedded. Depanarea interactivă nu oferă o indicație clară a comportamentului în timp real al unei aplicații.
O alternativă la depanarea interactivă este depanarea printf. Aici, dezvoltatorii pot adăuga instrucțiuni printf în aplicația lor pentru a genera un feedback semnificativ privind execuția codului în poziții semnificative. Aceste mesaje sunt apoi afișate într-un terminal de pe calculator, permițând dezvoltatorului să înțeleagă comportamentul aplicației. În cazul în care nu există o interfață disponibilă pentru transmiterea mesajelor, pinii I/O pot fi comandați ca alternativă la instrucțiunea printf. Un avantaj al depanării printf este că nu necesită oprirea aplicației, păstrând astfel comportamentul în timp real. Totuși, acesta este un proces intruziv. Prin urmare, pe măsură ce se adaugă mai multă instrumentație, impactul acestei metode asupra comportamentului în timpul execuției crește.
Prin urmare, soluția finală ar fi o tehnică de depanare care să ofere o perspectivă completă asupra execuției aplicației, precum depanarea interactivă și, în același timp, să păstreze caracteristicile de timp real, precum depanarea printf, dar, în mod ideal, fără instrumentare.
Aici intervine tracing-ul: acesta creează o listă de evenimente cu marcaje temporale care reprezintă comportamentul și fluxul în timp al aplicației. Scrierile și citirile variabilelor globale creează un mesaj de urmărire a datelor, un eveniment de urmărire cu adresa variabilei, valoarea care a fost citită sau scrisă și, bineînțeles, marcajul temporal corespunzător – așa-numita urmărire a datelor (data-trace).
Instrucțiunile creează evenimente cu adresa și codul operațional al instrucțiunii. Această formă de urmărire se numește urmărire a fluxului programului sau urmărire a instrucțiunilor – program flow trace, pe scurt. Combinând data-trace și program flow trace, dezvoltatorul obține o imagine completă a comportamentului în timp real al unei aplicații, de exemplu, prin vizualizarea datelor în analizatorul winIDEA al iSYSTEM. Dar cum poate fi înregistrată urmărirea?
Tehnici de tracing
În general, există două tehnici principale: tracing software și tracing hardware.
Similar cu depanarea printf, tracing-ul software se bazează pe instrumentarea software. Instrumentarea generează mesaje de urmărire în punctele de interes și le memorează în memoria microcontrolerului. De acolo, datele sunt transmise în afara cipului prin intermediul unei interfețe de aplicație, cum ar fi CAN sau Ethernet. Avantajul tracing-ului software este că nu necesită hardware special. Dar, din nou, există limitări în ceea ce privește numărul obiectelor de urmărit și durata urmăririi. La fel ca depanarea printf, tehnica este intruzivă și creează o supraîncărcare în aplicație.
Pe de altă parte, tracing-ul hardware se bazează pe un modul de urmărire integrat în cip pentru înregistrarea evenimentelor. Aceste evenimente sunt apoi trimise de pe cip prin intermediul interfeței de depanare sau al unei interfețe de tracing dedicate. Avantajul major al tracing-ului hardware este acela că nu creează niciun fel de supraîncărcare și nu perturbă aplicația. De asemenea, permite urmărirea mai multor obiecte și a unor înregistrări mult mai lungi în comparație cu tracing-ul software: în funcție de aplicație, sunt posibile durate de urmărire de la câteva secunde la câteva minute.
În plus, tracing-ul hardware permite mai multe cazuri avansate de utilizare, cum ar fi depanarea aplicației prin resetare, profilarea nelimitată a sistemului de operare, analiza de acoperire a codului și înregistrarea evenimentelor periferice, cum ar fi întreruperi sau accesări directe ale memoriei. Cu toate acestea, tracing-ul hardware trebuie să fie disponibil pe microcontrolerul utilizat și necesită hardware dedicat, cum ar fi un depanator/analizator iSYSTEM.
În sfârșit, este disponibilă și o a treia metodă, prin combinarea elementelor de urmărire hardware și software – hybrid tracing. De exemplu, ARM CoreSight System Trace System Macrocell STM generează automat mesaje de urmărire a datelor pentru operațiunile de scriere într-o zonă de memorie dedicată. Alte exemple includ Renesas RH850 (trace software) și PowerPC (trace massages). Aceste tehnici hibride sunt, de asemenea, denumite ‘instrumentation trace’.
Hardware Tracing
Dar cum funcționează tracing-ul hardware? După cum s-a menționat deja, acesta se bazează pe un modul de urmărire dedicat integrat în cip. Modulul are diverse submodule pentru înregistrarea fluxului programului, a urmăririi datelor și a instrumentării. În funcție de arhitectura microcontrolerului, utilizatorul are mai multă sau mai puțină libertate pentru a configura fiecare dintre aceste înregistrări din submodule. De exemplu, utilizatorul poate limita urmărirea fluxului programului pentru o funcție specifică sau poate înregistra doar anumite variabile globale cu urmărirea datelor.
Datele înregistrate sunt apoi comprimate și împachetate într-un mesaj de urmărire (trace message). În funcție de interfață, mesajul de urmărire este trimis direct în afara cipului sau este pus în buffer și citit de depanator. În cele din urmă, datele ajung la PC-ul gazdă, unde un instrument de depanare, cum ar fi iSYSTEM winIDEA, le procesează pentru a fi analizate de către utilizator (figura 1).
Diagrama bloc a dispozitivului Infineon AURIX
În acest moment, este important să înțelegem că modulul de urmărire de pe cip utilizează compresia pentru a permite înregistrarea pentru perioade de timp semnificative, în special pentru urmărirea fluxului programului. În mod obișnuit, acest lucru înseamnă că numai valorile contorului de program care creează un flux de program non-secvențial, cum ar fi salturile și excepțiile, creează un mesaj de urmărire. Instrumentul de depanare reconstruiește apoi secvența completă de instrucțiuni pe calculatorul gazdă.
În sfârșit, în funcție de modulul de urmărire și de interfață, marcajele temporale sunt adăugate la urmărire fie pe cip, fie de către depanator.
Interfețe ‘trace’
Există două tehnici pentru transferul datelor de urmărire (trace data) de la microcontroler. Prima utilizează interfața standard de depanare. Dispozitivul de urmărire de pe cip stochează mesajele de urmărire într-un buffer de urmărire dedicat pe cip, de unde depanatorul le citește prin intermediul unui port de depanare obișnuit, cum ar fi JTAG sau DAP. A doua tehnică, mai puternică, utilizează un port de urmărire. Un ‘trace port’ este o interfață serială sau paralelă dedicată care permite sistemului de urmărire pe cip să trimită evenimentele de urmărire direct către depanator. Un port de urmărire dedicat oferă rate de date mult mai mari, dar necesită un număr mai mare de pini.
Dar nu toate microcontrolerele sunt “trace-ready” din oficiu: Unele nu au nicio capabilitate de urmărire sau, chiar mai rău, oferă urmărire, dar portul de urmărire de pe PCB este inaccesibil. Dar există o soluție pentru aceste scenarii: așa-numitul ‘adaptor emulator’, disponibil pentru multe familii de microcontrolere și care înlocuiește microcontrolerul de pe PCB. Adaptoarele conțin un derivat mai mare al microcontrolerului, inclusiv o unitate de urmărire și un port de depanare sau de urmărire.
Pentru microcontrolerele Infineon AURIX din prima generație și pentru multe alte familii, inclusiv pentru procesoarele AURIX TC3xx din a doua generație, sunt disponibile asemenea adaptoare de la iSYSTEM și de la alți furnizori.
Cum se înregistrează o urmărire
Un prim exemplu de aplicație descrie înregistrarea unui traseu “conștient” de sistemul de operare cu ajutorul instrumentului de depanare winIDEA. Profilerul winIDEA oferă informații detaliate despre sistemul de operare AUTOSAR, inclusiv despre comportamentul temporal al sarcinilor, ISR (Interrupt Service Routines) și runnables (profilare RTE). Deși acest lucru ajută la depanarea problemelor legate de sincronizare, ar putea fi obligatoriu să se facă acest tip de analiză în domenii specifice. De exemplu, standardele de siguranță impun verificarea constrângerilor de timing și de încărcare a CPU.
Figura 2: Urmărire în funcție de sistemul de operare pentru depanarea problemelor de sincronizare și măsurarea utilizării CPU. (© iSYSTEM)
În primul exemplu, dezvoltatorul utilizează un computer cu sistem de operare Windows pe 64-biți și winIDEA, un BlueBox IC5700 și un Active Probe de la iSYSTEM. Microcontrolerul țintă al configurației de urmărire este un NXP S32K148 care rulează o aplicație bazată pe sistemul de operare ETAS RTA. S32K148 dispune de un nucleu Cortex M4 și este montat pe o placă de evaluare iSYSTEM. Placa de evaluare are un conector de depanare Cortex + ETM cu 20 de pini care pune la dispoziția depanatorului interfața de urmărire paralelă cu patru pini. În acest exemplu, se utilizează o urmărire paralelă, dar urmărirea este posibilă și fără un conector ETM, mulțumită așa numitului ‘trace SWO’ (Single-Wire-Output), care face parte din IP CoreSight ARM Cortex-M CoreSight.
Atunci când utilizatorul începe înregistrarea urmăririi, cronologia Profiler afișează sarcinile, ISR-urile și Runnables (figura 2). Secțiunile gri indică faptul că un obiect este inactiv, în timp ce secțiunile roșii arată că o sarcină sau un ISR sunt active. Albastrul indică o activitate ridicată; utilizatorul trebuie să facă un zoom pentru o vizualizare detaliată.
Resetarea urmăririi
Figura 3. Înregistrarea datelor înainte și după resetarea aplicației. (© iSYSTEM)
Al doilea exemplu ilustrează deosebit de bine avantajele urmăririi. Depanarea unui sistem embedded este extrem de dificilă dacă dezvoltatorului îi lipsește contextul în care aplicația opera înainte de eroare. Acest lucru se poate întâmpla atunci când stiva este coruptă sau când, ca în acest exemplu, aplicația se resetează din motive necunoscute.
La prima vedere, aplicația – bazată pe sistemul de operare Vector MICROSAR OS cu un microcontroler Infineon AURIX TC399XE pe o placă de evaluare iSYSTEM – rulează fără probleme. Cu toate acestea, dezvoltatorul suspectează că există resetări sporadice. Pentru a confirma această ipoteză, utilizatorul setează un punct de întrerupere la simbolul de pornire în cadrul winIDEA. Într-adevăr, după câteva momente, aplicația se oprește la adresa vectorului de resetare. Stiva de apeluri este goală după o resetare și, prin urmare, nu este utilă pentru găsirea cauzei. Registrul RCU (Reset Control Unit) confirmă, de asemenea, că a avut loc o resetare a aplicației. Această problemă este greu de rezolvat cu depanarea interactivă. În acest scenariu, urmărirea este din nou utilă.
O tehnică numită “depanare postmortem” poate fi utilizată pe microcontrolerul AURIX MCU. Pentru aceasta, unitatea de urmărire este instruită să înregistreze în emulatorul de memorie într-o procedură de tip ‘round-robin’. Atunci când aplicația atinge un anumit eveniment de declanșare, înregistrarea se oprește, iar depanatorul citește datele. Este chiar posibil să se configureze astfel încât datele să fie înregistrate atât înainte, cât și după evenimentul în cauză.
Cursorul poate fi utilizat pentru a afișa instrucțiunile executate în fereastra de urmărire în mod sincron cu timeline-ul profilerului și cu evenimentele de urmărire. În exemplul descris, așa cum era de așteptat, aplicația însăși declanșează resetarea. Mergând înapoi în timp, dezvoltatorul poate vedea că resetarea are loc fie atunci când un anumit semnal este setat la unu, fie atunci când se primește un mesaj CAN ce conține o anumită sarcină utilă (figura 3). Se pare că acesta din urmă este cazul, după cum indică funcția CAN-receive, care rula inainte de runnable. Astfel, cu ajutorul urmăririi hardware, a fost posibil să se găsească cauza principală a unei erori care ar fi fost dificil de localizat altfel.
Concluzie
Depanarea unei aplicații embedded necesită mult timp și, în multe cazuri, este extrem de dificilă cu metodele standard care interferează cu comportamentul în timp real. Cu toate acestea, urmărirea hardware sprijină dezvoltatorul în găsirea erorilor pentru care clarificarea cauzei principale ar fi fost o adevărată provocare cu alte tehnici. Urmărirea hardware necesită hardware suplimentar și instrumente adecvate – dar acest lucru se răsplătește din plin cu rezultate rapide de depanare, datorită unor informații profunde despre execuția aplicației.
Despre autor:
Felix Martin este inginer de sistem la iSYSTEM. El deține o diplomă de master în inginerie informatică de la Ostbayerische Technische Hochschule Regensburg și este un specialist cu multă experiență în software embedded în C/C++, depanare, Linux și algoritmi. El își împărtășește în mod regulat cunoștințele în cadrul unor webinarii gratuite de la iSYSTEM. E-Mail: felix.martin@isystem.com
