Praktyczne korzyści jakie przenosi projektantom ARM CoreSight

Jest kilka praktycznych udogodnień w pracy z mikrokontrolerami opartymi o rdzenie Cortex-M3 i M4, które niesie ze sobą architektura CoreSight oraz kilka wad i problemów, które trzeba mieć na uwadze.

Korzyści to:

• mniejsza liczba niezbędnych wyprowadzeń w układzie scalonym niż przy tradycyjnym JTAG’u,
• możliwość podglądu danych w czasie rzeczywistym, w trakcie pracy aplikacji, bez wprowadzania zmian w jej zachowaniu,
• możliwość wykorzystania niezbyt kosztownego debugowania za pomocą funkcji printf() poprzez kanał instruction trace macrocell (ITM),
• możliwość statystycznego profilowania aplikacji,
• możliwość debugowania w trybach obniżonego poboru energii,
• wykorzystanie mało kosztownych obliczeniowo tzw. próbników debugujących (ang. debug probes),
• możliwość raportowania przerwań i innych zdarzeń,
• łatwość pomiarów czasu wykonywania sekcji kodu dzięki wykorzystaniu znaczników czasowych.

Do wad natomiast można zaliczyć:

• transfer danych z wykorzystaniem pojedynczego pinu SWO skutkujący pewnymi ograniczeniami przepustowości (w niektórych układach dostępne są interfejsy 4-bitowe, przy ich wykorzystaniu koszta debugowania wzrastają jednak znacznie),
• monitorowanie stanu danych w czasie rzeczywistym jest ograniczone przez liczbę dostępnych w układzie komparatorów (typowo czterech),
• śledzenie wykonanych instrukcji jest możliwe w układach z 4-bitowym interfejsem debugingowym, nie ma w nich jednak możliwości śledzenia danych.

Aby porównać środowiska do debugowania wykorzystujące architekturę CoreSight i tradycyjnego JTAG’a warto prześledzić rysunki 2 i 3 zamieszczone poniżej.

Rys. 2. Widok okna programu w czasie debugowania z wykorzystaniem tradycyjnej metody run/stop

Rys. 3. Widok okna programu w czasie debugowania z wykorzystaniem Serial Wire Viewer

Na rysunku 3 widoczne jest wiele dodatkowych informacji, wliczając w to:

• wykresy wartości zmiennych w pamięci aktualizowane w czasie rzeczywistym, bez ingerencji w pracę układu (na rysunku są to wartości zmiennych X-Y-Z akcelerometru),
• statystyczny profil czasu, jaki aplikacja „spędza” w różnych miejscach kodu,
• komunikaty realizowane za pomocą funkcji printf() poprzez ITM z funkcji obsługujących akcelerometr,
• indeksowany czasem wystąpienia spis wszystkich przerwań systemowych wraz z opisami,
• statystyki dotyczące przerwań i wyjątków.

Podstawową cechą wszystkich tych informacji jest sposób ich prezentacji. W mgnieniu oka projektant może zwizualizować stan aplikacji i uzyskać odpowiedź na podstawowe pytania:

• czy dane z czujników zmianiają się na bieżąco zgodnie z przewidywaniami?
• czy przerwania są uruchamiane w odpowiednich momentach i w odpowiedniej kolejności?
• czy aplikacja spędza znaczne okresy czasu w konkretnych miejscach?

Są to bardzo wartościowe informacje w momencie gdy wszystkie części systemu, np.: sterowniki peryferiów, kod aplikacji, RTOS, stos TCP/IP, system plików użyty w pamięci Flash oraz stos USB są już połączone. Problemy z jednym z fragmentów kodu mogą wtedy być spowodowane przez problemy w innym, pozornie nie związanym, fragmencie. W takim wypadku, konkretne dane przekształcone w informację wizualną pozwalają szybko zlikwidować wiele potencjalnych kłopotów.