W dzisiejszym artykule chciałbym po raz kolejny poruszyć praktyczne aspekty prototypowania systemów wbudowanych, a zwłaszcza spojrzeć na problemy, z którymi musi zmierzyć się konstruktor. I tym razem będzie to coś prosto z “placu budowy” 🙂

Zapewne część z Czytelników, która miała kiedykolwiek do czynienia z podzespołami elektronicznymi wie, iż każdy element posiada swoje oznaczenie. W przypadku prostych elementów pasywnych (rezystory, kondensatory, itp.) jest to ich wartość nominalna i ewentualnie dozwolone napięcie pracy. Nieco bardziej złożone podzespoły, w tym półprzewodniki są już zazwyczaj opisywane alfanumerycznym symbolem typu. Dobrym przykładem jest tu nasz mikrokontroler STM32F429ZTI6. Ujednolicenie i skatalogowanie wszystkich typów i modeli podzespołów pozwala konstruktorom o wiele łatwiej projektować układy oraz upraszcza ewentualną ich naprawę.

Innymi słowy znajomość oznaczenia elementu zasadniczo powinna implikować dokładną wiedzę na temat parametrów czy funkcjonalności danego podzespołu…

Jednak czy aby na pewno?

Czym jest rewizja?

Jak wiadomo, im bardziej skomplikowany i złożony jest dany produkt, tym większe prawdopodobieństwo, iż na etapie projektowania lub produkcji wkradnie się błąd. Podobnie rzecz się ma z mikrokontrolerami. Nierzadko dopiero kiedy nowa seria trafi w ręce odbiorców, okazuje się, że nie wszystkie funkcjonalności działają poprawnie w każdych warunkach. Niestety w takiej sytuacji nie ma już możliwości naprawy usterek, gdyż wiązałoby się to z.. fizyczną ingerencją w krzemową płytkę, na której wytrawiono strukturę scalaka.

W takim wypadku producent układów przygotowuje niezbędne korekty do projektu i wdraża je na linii produkcyjnej. Zestaw takich poprawek nazywany jest właśnie rewizją. “Nowe” podzespoły, choć posiadają identyczne oznaczenie typu, muszą być w jakiś sposób odróżnialne od swoich wadliwych poprzedników. W tym celu wprowadza się dodatkowy symbol, najczęściej literowy lub liczbowy ,który pozwala określić z jaką rewizją układu mamy do czynienia.

Ponadto publikowana jest errata, zawierająca szczegółowe informacje dotyczące istniejących problemów, zauważonych w każdej z rewizji. Jeśli daną usterkę można ominąć lub ograniczyć jej występowanie metodami czysto software’owymi, w erracie znajdziemy także dokładny opis jak to osiągnąć.

Problemy z prototypem

Uruchamiają drugi prototyp urządzenia przeznaczony do testów w samochodzie, zauważyłem bardzo niepokojące zniekształcenia obrazu, widoczne na poniższym zdjęciu.

Pierwsze podejrzenie padło oczywiście na zasilanie. Jednak po skontrolowaniu wszystkich szyn zasilania i kondensatorów odsprzęgających stwierdziłem, iż to nie tu leży problem. Ostatecznie wykluczyłem wpływ jakichkolwiek zakłóceń, obniżając taktowanie zegara ze 180MHz do 30MHz. Kolejne eksperymenty skierowały moją uwagę na kontroler FMC. Jak pamiętamy pełni on w naszym systemie podwójną rolę: steruje wyświetlaczem LCD oraz stanowi interfejs do zewnętrznej pamięci SDRAM. Zauważyłem, że dokładnie co ósma kolumna pikseli jest wygaszona, co pokrywało się z formą transmisji obrazu na wyświetlacz. Z bufora obrazu odczytywanych jest bowiem jednocześnie 8 kolejnych pikseli, a następnie są one wysyłane kolejno do wyświetlacza LCD.

To skłoniło mnie do przeglądnięcia erraty dla układów STM32F4xx. Natrafiłem tam na ciekawy problem, pasujący do poczynionych obserwacji: Section 2.11.7: FMC dynamic and static bank switching

Jak widać, problem występuje w rewizjach: A, Y and 1. Poprawiony został w rewizji 3. Zgodnie z architekturą, SDRAM jest obsługiwany jako pamięć dynamiczna, czyli wymagająca odświeżania, zaś wyświetlacz LCD pracuje w trybie pamięci statycznej. Tak więc kopiowanie danych z pamięci na wyświetlacz wymaga przełączania się między dwoma bankami pamięci: dynamicznym i statycznym.

Płyta ewaluacyjna oraz pierwszy prototyp zawierały układy w wersji z rewizji 3. Oznacza to, iż na nich nie mieliśmy szans zauważyć tego problemu. Jak się okazało, do drugiego prototypu trafił nieco starszy układ, w rewizji Y. Wymiana mikrokontrolera rozwiązała problem.

Errata podaje co prawda rozwiązanie (czy raczej obejście…) problemu, które polega na przełączeniu pamięci SDRAM w tzw. tryb self-refresh każdorazowym przed dostępem do pamięci statycznej (czyli wyświetlacza LCD). W naszym przypadku jest to jednak nieakceptowalne ze względu na znaczący spadek wydajności oraz zmniejszenie częstotliwości odświeżania ekranu. Dzieje się tak ponieważ de facto na czas zapisu do pamięci statycznej wyłączamy bank SDRAM. Zaś jego ponowne uruchomienie pochłonie cenne mikrosekundy.

Podsumowanie

Mam nadzieję, że dzisiejszym artykułem choć trochę odczarowałem kolejny “magiczny problem” elektroniki. Jak widać nie zawsze wystarczy określić dokładnie typ układu scalonego – zwłaszcza w przypadku mikrokontrolerów i SoC’ów (System on Chip).

W hobbystycznych projektach bardzo rzadko zdarza się natrafić na tego rodzaju problemy – nam się to jednak udało! Jest to kolejne cenne doświadczenie i lekcja na przyszłość.