Elektroda.pl
Elektroda.pl
X
Computer ControlsComputer Controls
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

[SAM9260]SDRAM 16MB-działa, 32MB-nie działa

08 Lip 2011 00:19 2254 3
  • Poziom 27  
    Witam,
    zrobiłem płytkę prototypową na AT91SAM9260 z 16MB SDRAM na pokładzie.
    Bujam na niej linuxa, wszystko chodzi bez problemów.
    Skrypty SAM-BA dostosowałem z wzorca z płytki deweloperskiej AT91SAM9260-EK mającej 64MB SDRAM.
    Zastosowana przeze mnie pamięć 16MB to MT48LC4M32B2-7 w TSOP86:
    (1M x 32bit x 4 banki), adresowanie wierszy 12bit, kolumn 8 bit, refresh rate standardowy 15,6us/wiersz.

    Pamięć pracuje z zegarem 99,328MHz. Timingi pamięci nie wymagają zmian w stosunku do dev-boarda (sprawdzone w DS pamięci 16MB). Refresh rate ustawiony jest tam na 7us/wiersz, zostawiłem bez zmian (niewielkie obniżenie wydajności).

    W skryptach SAM-BY (inicjalizacja SDRAM) oraz w bootstrapie jedyną rzecz jaką musiałem zmienić było przestawienie konfiguracji pamięci SDRAM (w dev-boardzie jest pamięć o 13 bitowej adresacji wierszy i 9 bitowej adresacji kolumn).

    OK, skrypty dostosowane, wszystko hula...

    Z pewnych względów zaszła konieczność zwiększenia dostępnej ilości RAM, zatem
    znalazłem kostkę w obudowie TSOP86 w Farnellu (IS42S32800D-7TL) o zgodnej pinologii i dwukrotnie większej pojemności (32MB).
    Organizacja pamięci - 2M x 32 bit x 4 banki (adresowanie wierszy 12bit, kolumn 9 bit), refresh rate standardowy.
    Porównałem DS-y obu pamięci (16 i 32MB) i jedyna różnica jaką znalazłem to ilość bitów przy adresowaniu kolumn.
    Ponieważ, dostosowanie kontrolera SDRAM nie pozwoliło na uruchomienie układu z większą kością RAM, przestudiowałem DS-y obu kości RAM bardziej dogłębnie.
    Timingi identyczne przy zegarze 100MHz, odświeżanie identyczne, procedura inicjalizacji identyczna, jedyna różnica jaką zauważyłem to adresowanie kolumn - różnica 1 bitu w konfiguracji kontrolera SDRAM w AT91. No i większa pamięć pobiera nieco mniej prądu.

    Jednak układ po dostosowaniu kontrolera nie chce działać poprawnie, tzn.:

    SAM-BA po dostosowaniu skryptów poprawnie (?) inicjalizuje SDRAM, zapisuję do niego 32MB przypadkowych danych, później to weryfikuję i jest wszystko OK.
    Ale...
    nie jestem w stanie zaprogramować NAND flasha (z kością SDRAM 16 MB, po dostosowaniu skryptów SAM-BY oczywiście, wszystko jest ok).

    NANDa mogę skasować, odczytać info o zapsutych blokach, skasować informację o złych blokach, natomiast wykonanie jakiejkolwiek operacji na NAND, gdzie wykorzystywany jest bufor odczytu/zapisu w SDRAM kończy sie zwiechą SAM-BY.

    I nie wiem co o tym myśleć. Testy zapis/odczyt SDRAM spod SAM-BY przebiegają bez problemów, ale uruchomienie kodu z SDRAM - już nie przebiega poprawnie.

    Eksperymentując i szukając przyczyny problemu pominąłem SAM-BĘ i przygotowałem programatorem bezpośrednio w NAND:
    - bootstrapa konfigurującego kontroler SDRAM do obsługi 32MB ram,
    - i U-boota. Kernel ściągam przez TFTP z zewnętrznego serwera.

    Bootstrap zawiera prostą procedurę testującą SDRAM, która przebiega bez zakłóceń (3 wzorce sekwencyjnie),
    poprawnie uruchamiany jest uboot, z linii poleceń mogę wykonać dowolną operację,
    natomiast po zabootowaniu kernela, widzę, że jądro jest rozpakowywane poprawnie i gdy już ma wystartować wszystko zamiera.
    Z analizy debugu wynika, że wiesza się tuż przed, lub w trakcie inicjalizacji konsoli.

    Na tej samej płytce, po włożeniu kości 16MB, (i dostosowaniu kontrolera SDRAM) wszystko chodzi bez problemów.
    Podstawiałem drugi egzemplarz pamięci 32MB, podejrzewając pierwszy o uszkodzenie, problem nie ustąpił.
    Raczej mało prawdopodobne jest abym ubił dwie kości, albo kupił 2 felerne sztuki.
    Zasilanie 3V3 czyste... Brakuje mi już pomysłów co jeszcze może być nie tak.

    Co wg Was, powinienem jeszcze sprawdzić?
  • Computer ControlsComputer Controls
  • Użytkownik usunął konto  
  • Computer ControlsComputer Controls
  • Poziom 27  
    Eksperymenty z odświeżaniem już też za mną. :)

    Zmieniałem szybkość odświeżania w bardzo szerokich granicach (1us-17us) - nie dało to pozytywnych efektów, niestety... Zmiany potwierdzałem obserwacjami na oscyloskopie.

    Layout płytki już tu pokazywałem:
    https://www.elektroda.pl/rtvforum/viewtopic.php?p=9104175#9104175

    [SAM9260]SDRAM 16MB-działa, 32MB-nie działa

    Zmieniałem także timingi pamięci - (zwiększałem) na różne sposoby - (parametry czasowo pojedynczo oraz kilka jednocześnie chcąc 'wyczuć' która z wartości może mieć krytyczne znaczenie), o różne wartości, bez poprawy, było czasami tylko gorzej.

    P.S. Ciekawostka, aby uniknąć kompilowania apletu obsługi SDRAM dla SAMBY, można wartości wyedytować bezpośrednio w pliku
    isp-extram-at91sam9260.bin:
    timingi pamięci (wartość 0x85227259):
    [SAM9260]SDRAM 16MB-działa, 32MB-nie działa
    refresh rate (wartość 0x000002b7):
    [SAM9260]SDRAM 16MB-działa, 32MB-nie działa
  • Poziom 27  
    Problem definitywnie rozwiązało zastosowanie terminatorów w szereg z liniami danych / adresów / kontrolnymi.

    Dodatkowo, podczas projektowania kolejnej PCB zminimalizowałem ilość przelotek
    w obrębie CPU - SDRAM przestawiając bajty w obrębie szyny danych oraz kolejność bitów.

    Zrobiłem PCB dla pamięci 16 bit w TSOP54 (lewa PCB) i dla pamięci 32 bit w TSOP86 (prawa PCB):
    [SAM9260]SDRAM 16MB-działa, 32MB-nie działa

    Zastosowane terminatory:
    [SAM9260]SDRAM 16MB-działa, 32MB-nie działa [SAM9260]SDRAM 16MB-działa, 32MB-nie działa

    Dla pamięci K4S281632 wartość 22R wydała się optymalna, płytka działa bezproblemowo.
    Dla pamięci IS42S32800D okazało się, że wartość terminatorów trzeba dobrać.
    Przy 22R problemy z SAM-BĄ ustąpiły, ale linux czasem się wysypywał w najmniej spodziewanych momentach.
    Nie miałem innych oporów pod ręką więc w szereg dałem po dwie drabinki uzyskując 44R. Płytka stała się stabilna jak skała :)

    P.S. jako ciekawostka: Szybkie porównanie wydajności systemu pracującego z pamięcią 16bit i 32bit.
    Testy zrobione na jądrze 2.6.39.
    Różnice w sofcie płytek - tylko bootstrap, gdzie ustawiany jest konfiguracja pamięci, reszta taka sama.
    Testy zrobione programem czytającym/zapisującym bloki sekwencyjnie.
    Dla rozmiarów bloków w zakresie 1kB-8kB rezultaty są praktycznie identyczne (działa cache?),
    dla bloków większych (16k-8M) układ z pamięcią 16bit jest oczywiście wolniejszy. Przy odczycie - ok 18%, przy zapisie ok. 25% w porównaniu do układu z 32bit SDRAM.