Projektowanie elektroniki - metody i strategie implementacji nowości technologicznych

Narzędzia

Rys. 5. Przykładowa sesja debugowania mikrokontrolera z rodziny STM32 w środowisku Raisonance (Ride 7 + Rlink)

Duże ułatwienie podczas pisania oprogramowania stanowią narzędzia, zapewniające "wgląd" w funkcjonowanie zastosowanego układu (np. mikrokontrolera, FPGA, podzespołów analogowych), tzn. pozwalające na bieżąco monitorować stan, w jakim się on znajduje. Najbardziej podstawowym przyrządem jest oscyloskop, który umożliwia obserwację przebiegów napięcia w wybranych punktach urządzenia. Rozsądne minimum stanowi oscyloskop wyposażony w dwa kanały, jednakże warto zainwestować w sprzęt wyposażony w cztery kanały.

Za pomocą oscyloskopu można zweryfikować, czy przebiegi występujące w urządzeniu mają wymagane parametry (częstotliwość, amplituda) oraz dokonać wstępnej analizy przesyłanych sygnałów i określić, czy odpowiadają one oczekiwaniom. Przykładem może być obsługa kodeków AC97, które komunikują się poprzez interfejs szeregowy.

Wykorzystując oscyloskop czterokanałowy do obserwacji sygnału zegarowego, linii nadawczej, odbiorczej oraz sygnału synchronizacji, można określić m.in., czy kodek wytwarza sygnał zegarowy, czy przesyła dane synchronicznie do impulsów wystawianych na wejściu Sync lub na podstawie obserwacji zbocza sygnału zegarowego i linii danych odczytać zawartość niektórych rejestrów. Jest to pomocne podczas określania, czy nie powstały błędy sprzętowe, montażowe lub czy nie popełniono błędu w oprogramowaniu.

Bardziej złożone oscyloskopy mają zaawansowane funkcje wyzwalania (np. sygnałami I2C, SPI, CAN, HDTV), analizy jittera, mocy oraz standardów takich jak Ethernet, USB, HDMI, SATA, DVI czy PCI-Express. Oscyloskopy zawierają mocno ograniczoną liczbę kanałów i nie umożliwiają pełnej analizy układów wykorzystujących wiele linii sygnałowych, np. w dyskach twardych czy wyświetlaczach. W sytuacji, gdy są to układy cyfrowe, znacznie lepiej pod tym względem sprawdza się analizator stanów logicznych.

Może on mieć nawet parędziesiąt kanałów wejściowych, pozwalając tym samym obserwować stan magistral adresowych, danych, sterujących. Na tej podstawie łatwo jest określić, czy przesyłane sygnały są zgodne z oczekiwaniami. Analizator stanów logicznych bywa przydatny również podczas pracy z układami programowalnymi, gdyż zapewnia podgląd sygnałów przesyłanych pomiędzy układem programowalnym a układami zewnętrznymi.

Ponadto możliwe jest wyprowadzenie wewnętrznych sygnałów FPGA na fizyczne porty i ich obejrzenie. Na tej podstawie łatwiej wyszukać nieprawidłowości w funkcjonowaniu zaprojektowanej logiki i szybciej usunąć błędy. Takie podejście może okazać się pomocne choćby podczas projektowania modułu konwertującego standard RS232 na postać równoległą, która jest łatwiejsza do wykorzystania w układach programowalnych.

Doprowadzając wejścia i wyjścia takiego modułu do fizycznych wyprowadzeń układu FPGA, można za pomocą analizatora obejrzeć wszystkie te sygnały. Pozwoli to łatwo sprawdzić, czy odpowiedź układu na doprowadzony sygnał RS232 jest poprawna, tzn. czy bajt przesłany w postaci szeregowej jest zamieniany na postać równoległą. W sytuacji, gdy w układach FPGA wykorzystywane są automaty, można łatwo sprawdzić w jakim stanie się one obecnie znajdują.

Wystarczy wtedy wystawiać na wybrane porty I/O słowo wyjściowe niepowtarzalne dla każdego ze stanów, aby określić, jak pracuje zaprojektowany automat i gdzie się ewentualnie "zatrzaskuje". Można ponadto wykryć zabronione przejścia i szybciej ustalić, co je powoduje. Łączenie modułów w większe struktury bez uprzedniego sprawdzenia ich poprawności sprawi, że w razie błędu znacznie trudniej będzie określić, który z kilku modułów odpowiada za niepoprawną pracę całego układu.

Mając jednak pewność, że właściwie przetestowano niektóre komponenty, można z dużą dozą prawdopodobieństwa określić, że błąd znajduje się w jednym z nieprzetestowanych modułów. Zawęża to obszar poszukiwań i przyspiesza proces debugowania. Producenci układów programowalnych mają świadomość trudności związanych z projektowaniem logiki dla złożonych struktur FPGA i problemów, jakie stwarza wyszukiwanie błędów.

Pewnym rodzajem wsparcia są symulacje czasowe obrazujące przebiegi wybranych sygnałów w układzie programowalnym. Umożliwiają one stwierdzenie, czy kod napisany w języku HDL jest wolny od błędów logicznych. Oprócz symulacji możliwe jest uzyskanie wglądu w wewnętrzną strukturę FPGA i zapoznanie się z przesyłanymi w niej sygnałami oraz stanami poszczególnych komponentów (np. automatów). Możliwość taką daje np. ChipScope Pro opracowany przez Xilinksa.

Narzędzie to jest częścią środowiska projektowego ISE Design Suite (dostępne w 30-dniowej wersji ewaluacyjnej). Użytkowanie ChipScope jest proste i sprowadza się do wygenerowania dwóch modułów (ILA oraz ICON) za pomocą narzędzia Core Generator. Blok ILA (Integrated Logic Analyzer) jest konfigurowalnym elementem, dla którego można zdefiniować liczbę portów służących do monitorowania magistral i/lub pojedynczych linii.

Każdy z portów ma niezależnie konfigurowalną szerokość bitową. Po wygenerowaniu bloku ILA doprowadza się do niego sygnały, które mają zostać zaprezentowane na ekranie komputera. Dane na portach są pobierane w takt sygnału zegarowego doprowadzonego do wejścia wyzwalanie bloku ILA. Moduł ICON (Integrated Controller) odpowiada za wymianę danych pomiędzy komputerem oraz ILA, z tego względu do użytkowania narzędzia ChipScope niezbędny jest interfejs JTAG: Platform Cable USB I/II, Parallel Cable IV lub ByteTools Catapult EJ-1 Ethernet-to-JTAG Cable.

Narzędzie ChipScope jest zasadniczo analizatorem stanów logicznych umieszczanym wewnątrz struktury FPGA, więc sygnały oglądane na ekranie reprezentują rzeczywiste sygnały doprowadzone do modułu ILA. Po przeprowadzeniu syntezy projektu i konfiguracji układu programowalnego uruchomia się aplikację z pakietu ISE Design Suite. Pozwala ona określić warunki rozpoczęcia rejestracji (poziomy logiczne na wybranych liniach) oraz przeprowadzać pojedynczą lub ciągłą rejestrację.

Po zgromadzeniu całego rekordu danych na ekranie komputera rysowane są przebiegi czasowe lub wyświetlany jest listing, zależnie od wyboru użytkownika. Warto zauważyć, że zarówno pojedynczym sygnałom, jak i magistralom można nadawać dowolne nazwy, co znacząco podnosi czytelność prezentowanych wyników. Na rysunku 4 pokazano okno aplikacji podczas pracy. Warto dodać, że ChipScope Pro wspiera następujące rodziny układów: Virtex-6, Virtex-5, Virtex-4, Spartan-6 i Spartan 3.

Tabela 4. Przykłady graficznych, kolorowych wyświetlaczy

Rekord danych jest umieszczany w pamięci Block RAM, stąd jego rozmiar (liczba zapamiętywanych słów wejściowych) jest zależny od dostępności pamięci, na co wpływ ma wybór konkretnego układu programowalnego, stopień wykorzystania pamięci przez zaimplementowaną logikę oraz liczba monitorowanych linii sygnałowych. Warto zauważyć, że również inni producenci oferują podobne narzędzia zapewniające "wgląd" w działanie FPGA: SignalTap II czy CLAM przeznaczone dla produktów firm, odpowiednio, Altera oraz Actel.

Debugowanie staje się jeszcze łatwiejsze w sytuacji, gdy urządzenie jest oparte na nowoczesnym mikrokontrolerze zawierającym wbudowany interfejs debugujący. Umożliwia on podglądania stanu zmiennych, rejestrów oraz śledzenie programu w trybie krokowym. Duże ułatwienie stanowią pułapki programowe, gdyż dzięki nim procesor pracuje w czasie rzeczywistym i udostępnia obsługę wszystkich układów peryferyjnych.

Dopiero po wystąpieniu ściśle określonego warunku wykonanie programu zostaje wstrzymane, a stan procesora jest przekazywany do komputera. W ten sposób łatwiej jest znaleźć błąd, zwłaszcza gdy jest on związany z układami peryferyjnymi, np. transmisją szeregową, gdyż możliwa jest praca w trybie rzeczywistym. Standardowy scenariusz korzystania z narzędzi debugujących obejmuje sprawdzanie danych odbieranych i wysyłanych do układów peryferyjnych i śledzenie wykonania programu.

Na tej podstawie można stwierdzić, czy oprogramowanie prawidłowo przetwarza informacje, czy poszczególne fragmenty kodu są wykonywane oraz gdzie program ulega zawieszeniu. Przykładem skutecznego wykorzystania debuggera może być problem z wyświetlaniem daty w jednym z projektów realizowanych przez autora. Sprawdzając kolejno przekazywanie wartości z zewnętrznego zegara RTC na wyświetlacz, można było ustalić, że nieprawidłowe dane pojawiają się już podczas zapisu na LCD, w argumencie funkcji wyświetlającej datę.

Kolejnym krokiem było sprawdzenie zawartości klasy odpowiedzialnej za pobieranie danych. W jej wnętrzu również znajdowała się nieprawidłowa wartość, więc sprawdzono wartość odczytywaną z magistrali I²C. Po stwierdzeniu, że tutaj również występują nieprawidłowości, ustalono, że błąd tkwi w odczycie z układu zegara.

Po weryfikacji poleceń przesyłanych przez magistralę stwierdzono, że winę za ten stan rzeczy ponosi pomyłka przy adresowaniu wewnętrznego rejestru układu RTC. Bez możliwości wglądu w działanie programu i dokładnego śledzenia jego wykonania znalezienie błędu byłoby znacznie bardziej czasochłonne. Przykładową sesję debugowania mikrokontrolera z rodziny STM32 w środowisku Raisonance (Ride 7 + Rlink) przedstawiono na rysunku 5.