W dzisiejszym artykule chciałbym na pewnym przykładzie pokazać, jak wyglądają zmagania z problemami stricte sprzętowymi. Są one o wiele trudniejsze niż te związane z oprogramowaniem, gdyż nie można uniknąć ich za pomocą testów, a odnalezienie źródła wymaga czegoś więcej niż tylko uruchomienia debugera.

Na jaki problem natrafiliśmy?

Otóż jak pamiętacie, w naszym systemie zdecydowaliśmy się wykorzystać zewnętrzną kość pamięci SDRAM. Do jej obsługi wykorzystujemy zintegrowany kontroler pamięci FMC. O ile konfiguracja samego kontrolera nie nastręczyła większych problemów, to utknąłem na dobre przy próbie “ożywienia” kości pamięci. Aby uruchomić SDRAM należy wysłać do układu kilka poleceń, które odpowiednio skonfigurują kość.

W czym problem?

Otóż każdy producent i niemalże każdy model pamięci SDRAM posiada nieco inną strukturę rejestrów konfiguracyjnych. Dotychczas korzystałem z układów IS42S16400J
, które umieszczano m.in. na płytkach z serii STM32F4-DISCOVERY. Do budowy prototypu zdecydowałem się użyć układu IS42S16400B, który pozornie różnił się jedynie nieco niższą maksymalną częstotliwością taktowania.

Jak się okazało nie tylko 🙂

Objawy były bardzo interesujące i niepokojące zarazem. Niektóre cykle zapisu/odczytu udawały się, jednak zdecydowana większość była kończyła się przekłamaniami danych. I to w bardzo ciekawej formie, gdyż zapis 32 bitów (4 bajtów) skutkował dwukrotnym zapisaniem powtórzonych dolnych 16 bitów.

Pierwsze podejrzenie padło na płytkę PCB. Zdecydowana większość problemów z pamięciami SDRAM ma swoje źródło w niedostatecznym odsprzęgnięciu szyn zasilających, błędnym prowadzeniu ścieżek sygnałów lub masy. Czyli potencjalnie może to oznaczać konieczność wykonania od nowa projektu oraz prototypu PCB… A to zajmuje sporo czasu 🙁 Aby mieć pewność zdecydowałem się znacząco obniżyć taktowanie pamięci – wówczas wszelkie zakłócenia spowodowane stricte elektryczną częścią powinny być znacznie mniej uciążliwe.

Niestety okazało się, iż problem pozostał. To skłoniło mnie przyjrzeć się bliżej konfiguracji. Odkryłem pewien pozornie nic nieznaczący szczegół w dokumentacji. Otóż struktura rejestru konfiguracyjnego układów w wersji J umożliwia skonfigurowanie trybu zapisu sekwencyjnego za pomocą bitu A9.

Układy serii B już takowej opcji nie mają, a bit A9 oznaczono jako zarezerwowany.

Jak łatwo się domyślić, w używanej przez nas konfiguracji ustawialiśmy bit A9. Pozornie nie powinien mieć on znaczenia w układach serii B. Jednak jak się później okazało, jego “zgaszenie” naprawiło problem 🙂 Czyli jednak “miał znaczenie”…