[Rozwiązano] XMEGA128A1U - Problem z zapisem do SRAM AS7C34096A przez EBI w trybie LPC 2-portowym

Witam forumowiczów

Mam niemały problem z obsługą pamięci SRAM (AS7C34096A) podłączonej do uC XMEGA128A1U poprzez interfejs EBI w trybie LPC 2 portowym. Schemat podłączenia jest praktycznie identyczny z modułem "XMEGA A1U Xplained Pro", którego schemat można znaleźć na stronie atmel.com lub pod tym linkiem.

Teraz do rzeczy - wygląda na to, że komunikacja z układem SRAM działa, dane z konkretnej komórki pamięci program odczytuje zawsze takie same (bez zaniku zasilania pomiędzy odczytami). Jednak przy próbie zapisu (nieważne pod jaki adres) dane nie ulegają zmianie (po odczytaniu nadal mają poprzednią wartość). Nawet próbowałem zapisu całej pamięci jedną wartością, gdyby problemem było adresowanie, ale przy odczycie dane nadal były takie same.
Sygnały do układu dochodzą prawidłowe, sprawdzałem analizatorem stanów logicznych.

Program nie jest skomplikowany z racji sprzętowej obsługi EBI, tworzony był na podstawie noty katalogowej i książki "AVR Układy peryferyjne":

Inicjalizacja EBI:

Main:

Jakie masz taktowanie EBI? 64 MHz? Wtedy pamięć musi mieć czas dostępu <15 ns. Jakie użyłeś latche? Nie są za wolne?

Sprawdzałem przy różnym taktowaniu, między 4 a 64 MHz. Według specyfikacji pamięć ma czas dostępu 10 ns. Latche to dokładnie "SN74LV573ADW".

To jeszcze pytanie - schemat jest praktycznie identyczny, czy identyczny? Jeśli masz debugger to wymuś stany na IO i prześledź czy takie same stany masz na pinach pamięci.

Prawie identyczny, różni się układami 573. Docelowo ma być wykorzystany sygnał CS3 i A18 bezpośrednio do pamięci, ale na czas testów podłączałem CS2 (widać to w programie).
Sprawdziłem dzisiaj jeszcze raz stany na pinach pamięci z wykorzystaniem debuggera i wszystkie są takie jak powinny. Spróbowałem jeszcze ręcznie wysterować porty IO (bez użycia EBI) za pomocą kodu programu oraz debuggera i efekty są takie same, nie reaguje na zapis, odczyt zawsze zwraca taką samą wartość dla danej komórki pamięci, nie ważne, którym sposobem robiłem odczyt (EBI, program, ręcznie przez debugger). Dla przykładu komórka pamięci o adresie 0x8001 zwraca wartość 0xFF, 0x8002 zwraca 0xB0.

Jeśli softwarowo masz ten sam problem to jednak to wskazuje na jakiś problem z hardware. Dobrze podpiąłeś sygnały OE i CE? CS w tej pamięci to CE, a RD to OE. Ja bym sprawdzał połączenia do skutku, bo nie ma siły, gdzieś tam leży błąd. Na wszelki wypadek pokaż schemat.

Zacząłem sprawdzać wszystko od samego początku. Dotychczas porównywałem wszystko ze schematem - i tu problemu nie ma, całość zgodna, wszystkie połączenia prawidłowe. Natomiast problem zrodził się jeszcze przed stworzeniem schematu, a mianowicie podczas tworzenia elementu bibliotecznego dla konkretnej kości pamięci ... zamieniłem wtedy miejscami piny CE i OE, a później podczas weryfikacji nie zauważyłem tego. Głupie błędy zawsze najtrudniej zlokalizować, ehh :/
Teraz wszystko jest jasne i klarowne, działało prawidłowo, sygnał CS układ dostawał tylko w przypadku odczytu, dlatego zapis się nie dokonywał.

Dzięki za wspomnienie o sygnałach sterujących, a tym samym zmotywowanie mnie do sprawdzenia wszystkiego od początku.

Też mogę prosić o schemat?

W nocie masz przyporządkowanie pinów IO do sygnałów EBI. Użyj XMEGA A1U - mają poprawiony interfejs EBI, m.in. dostępna jest konfiguracja 4-portowa, niewymagająca, żadnych zatrzasków.

Tak wiem ale jestem ciekawy jak się łączy piny adresowe i który pin atxmega się podłącza do CS, nie wiem jak się łączy Chip Select w sytuacji gdy chcemy np 2 kości pamięci lub kość pamięci lub kość i wyświetlacz z CS1.
Nie rozumiem jak się wylicza który pin idzie do CSn.

Podłączenie wyświetlacza przez EBI to zazwyczaj kiepski pomysł - kontrolery LCD zwykle są zbyt wolne i nawet max wait statów nie pomaga, w efekcie trzeba zwalniać cały MCU. Szczególnie odczyt jest kulawy. Są wyjątki, ale rzadkie. Co do CS - wszystko zależy od tego jak skonfigurujesz to w MCU. Popatrz na opis EBI. XMEGA może generować 4 niezależne sygnaly CS.

Ok dzięki za tip. Nie wiem jaki pin xmega się podłącza do CSn gdy na kości pamięci kończą się piny adresowe. Czy jak mam 16 pinów adresów w kości to do CSn podłączam kolejny adres który w xmega jest jednocześnie CS0? To dlatego ostatnie piny adresowe xmega są jednocześnie CS0-3?

Ale zaraz co do tych LCD, przecież widać na filmy jak podłączają te różniste lcd zarówno z chin do arduino jak i od nokii do ARMór i bangla wszystko.
Może to jedna przetoczenie danych przez xmega kuleje to bym bardziej podejrzewał.

Widać np filmy jak 2 lcd po SPI jeden nad drugim podłączone pod jakieś raspbery i puszczają linuksa ledwo co jakąś smugę widać i normalnie pulpit odpalają.

jacynka84 napisał:

To dlatego ostatnie piny adresowe xmega są jednocześnie CS0-3?

Tak to działa.

jacynka84 napisał:

Ale zaraz co do tych LCD, przecież widać na filmy jak podłączają te różniste lcd zarówno z chin do arduino jak i od nokii do ARMór i bangla wszystko.

Owszem, tyle, że interfejs jest programowy.

jacynka84 napisał:

Może to jedna przetoczenie danych przez xmega kuleje to bym bardziej podejrzewał.

Co tu podejrzewać, wystarczy sprawdzić parametry. EBI w XMEGA to 64 MHz, okres więc wynosi <16 ns. Zapisy/odczyty do większości kontrolerów LCD to odpowiednio około 100/400 ns. Aby kontroler LCD się wyrobił musiałbyś wprowadzić 6-25 wait statów. A bywają wolniejsze kontrolery. Ponieważ aż tylu nie możesz wprowadzić, więc trzeba zwolnić EBI. Tyle, że to się odbije na dostępie do pamięci zewnętrznej, więc nie ma sensu, w dodatku zwolnienie EBI poniżej 32 MHz jest możliwe tylko jeśli zwolnisz zegar rdzenia MCU. W ARM problem będzie identyczny.

jacynka84 napisał:

Widać np filmy jak 2 lcd po SPI jeden nad drugim podłączone pod jakieś raspbery i puszczają linuksa ledwo co jakąś smugę widać i normalnie pulpit odpalają.

Po SPI to raczej niemożliwe. Przy zapisie w większości kontrolerów SPI może działać z ok. 10-15 MHz, to daje transfer 1,25-1,875 MB/s. Dla QVGA i 16bpp daje to <13 fps i cudów nie ma. A jeśli nie masz VRAM w pamięci procesora, to np. antyaliasing będzie wymgał odczytu GRAM z kontrolera, czego większość kontrolerów LCD po SPI nie umożliwia, a te, które to umożliwiają ślimaczą sie strasznie.
Generalnie dla rozdizelczości QVGA praktycznie nie ma różnicy w obróbce grafiki pomiędzy XMEGA a ARM CM0+ i większymi też - wąskim gardłem jest kontroler LCD. Przy większych rozdzielczościach użyłbym kontrolerów z jakąś akceleracją - np. RA8876, albo coś z rodziny FT8xx.

Jak programowy jak on jest jeszcze wolniejszy.
Po prostu rysujesz klatkę ale zamiast adresować piksel w lcd adresujesz do tablicy, a ona musi być w zewn ram zeby nie była podzielona np na ram w uK i w zewn kości.
I wtedy automat jak DMA przesyła dane z vram do lcd który też jest swoistym ramem. Lepsza by była sytuacja gdzie mamy w mikrokontrolerze dostateczną ilość ram i nawet chyba są takie
w których dałoby się pomieścić klatkę 320x240 16bit, ale i tak trzeba by wtedy powiesić lcd na szynie zewn ramu jak EBI.
https://www.youtube.com/watch?v=gJxs3Rm0aTU
https://www.youtube.com/watch?v=0ox6p5-im7c

jacynka84 napisał:

Jak programowy jak on jest jeszcze wolniejszy.

Jeszcze raz - wąskim gardłem dla transferu danych do GRAM kontrolera jest sam kontroler, a nie MCU. EBI jest zbyt szybki dla większości kontrolerów LCD, a biorąc pod uwagę, że ma ograniczoną elastyczność konfiguracji zegara, może w efekcie być wolniejszy niż interfejs programowy. Policz, sprawdź.

jacynka84 napisał:

I wtedy automat jak DMA przesyła dane z vram do lcd który też jest swoistym ramem. Lepsza by była sytuacja gdzie mamy w mikrokontrolerze dostateczną ilość ram i nawet chyba są takie

DMA nie prześle danych szybciej niż może je odebrać odbiornik - w tym przypadku kontroler LCD. Wyślesz szybciej - będą przekłamania.

jacynka84 napisał:

https://www.youtube.com/watch?v=gJxs3Rm0aTU
https://www.youtube.com/watch?v=0ox6p5-im7c

No to weźmy notę użytego kontrolera - ILI9341. W tabeli 19.3.4 masz charakterystykę jego magistrali SPI, a w niej m.in.:
- Serial clock cycle (Write) - 100 ns,
- Serial clock cycle (Read) - 150 ns.
To znaczy dokładnie tyle, że SPI może działać dla zapisu z max f=10 MHz, a dla odczytu z f=6,6 MHz. Czyli możesz przesłać do zapisu max 1,25 MB/s. To, że na filmiku ktoś napisał, że taktuje SPI na 40 MHz nie znaczy, że to będzie dobrze działać.
Teraz tabela 19.3.2, interfejs równoległy:
- Write cycle - 66 ns,
- Read Cycle (FM) - 450 ns !!!
To porównaj to z wymogami EBI w XMEGA - <16 ns! Jak widać dla zapisu potrzebujesz 5 WSów (dla 4 jesteś troszeczkę poza specyfikacją), ale dla odczytu potrzebujesz aż 29 WSów!! A tyle się zrobić nie da, więc trzebaby dramatycznie zwolnić całe EBI i MCU. Jak widać, w tym przypadku, programowa obsługa interfejsu równoległego będzie szybsza niż skorzystanie z EBI. Co więcej, akurat dla 8-bitowego MCU (XMEGA) programowo można podłączyć się do kontrolera z użyciem 16-bitowej magistrali danych, co znacznie przyśpieszy transfer.

Ale czemu się czepiasz read cycle. Na co to komu. Operacje (porównawcze?) na pikselach się dokonuje przez narysowaniem ramki a nie najpierw rysuje, zapisuje do gramu potem wysyła a potem nazad wydusza z lcd i cuduje to głupiego robota. Zresztą, nowe lcd używane w nowych telefonach chyba nie mają wideoramu mają jedynie kontroler a GRAM to jednocześnie ram ARMa na szynie oczywiście. I nikt się nie bawi w wyciskanie danych z LCD.
Chyba ze chodzi o co innego. Wyjaśnisz po co ten read cycle?

Jeśli nie masz kopii GRAM, to jak chcesz zrobić np. półprzeźroczystość? A to jest wymagane nie tylko dla jakiś bajerów, ale nawet przy zwykłym antyaliasingu się przydaje, jeśli tło nie jest jednolite i z góry znane.
Zresztą nawet pomijając tego typu efekty, załóżmy, że tylko chcesz zapisywać do GRAM. To i tak jak widać zapis trwa w trybie równoległym 100 ns, czyli 6 razy tyle co cykl dla EBI. Zamiast blokować WSami cały MCU, sensowniej jest to zrobić programowo (rozszerzając przy okazji magistralę do 16 bitów) i przeplatać dostęp do GRAM np. obliczeniami graficznymi.

jacynka84 napisał:

Zresztą, nowe lcd używane w nowych telefonach chyba nie mają wideoramu mają jedynie kontroler a GRAM to jednocześnie ram ARMa na szynie oczywiście. I nikt się nie bawi w wyciskanie danych z LCD.

Nie porównuj układów posiadających kilka GB RAM z układami, które mają niewiele więcej pamięci niż wymagany bufor ramki.

Nie porównuję. Mówię tylko że nie trzeba nic wyciągać z lcd. Wszystko wirtualnie. Choć fakt to nie na moce avr.
Ale porzućmy to to czego nie byłem pewny już wiem o tym sterowaniu CSn.
Chociaż ciekawi mnie jedna rzecz. SRAM nie manipuluje danymi w nim zapisanymi, no bo jak żeby inaczej miało to działać.
Piny adresów też nie pływają ani nic. Czy to znaczy że nie trzeba się przejmować które piny adresowe do których adresowych w kości idą jedynie żeby zakres się zgadzał? I to samo z liniami data? SRAM nie dowie się ani nic nie zrobi że zamieniliśmy mu np kolejność pinów data, ani adresowych?
Jedynie nie można do pinu ostatniego np A15 podać sygnału wyższego niż A15 co nie? Jak sobie uK wpisze tak wyciągnie.
Kiedyś w jakichś pamięciach sram nie było chyba nawet podane który pin to który w kolejności data ani adres, jedynie normalna pinologia.
To mocno upraszcza schemat.

jacynka84 napisał:

Choć fakt to nie na moce avr.

Nie chodzi o moce AVR, bo jak widać, o czym piszę od kilku postów, limitem jest możliwy do uzyskania transfer, ograniczany przez kontroler LCD i pamięć RAM jaka jest do dyspozycji. Ponieważ w typowych kontrolerach LCD GRAM nie jest normalnie widoczna w przestrzeni adresowej MCU, nawet stworzenie shadow-RAM dla LCD niewiele pomoże. Rozwiązania o jakich piszesz, to zupełnie inne rozwiązania sprzętowe, więc i możliwości są inne.

jacynka84 napisał:

Piny adresów też nie pływają ani nic. Czy to znaczy że nie trzeba się przejmować które piny adresowe do których adresowych w kości idą jedynie żeby zakres się zgadzał? I to samo z liniami data? SRAM nie dowie się ani nic nie zrobi że zamieniliśmy mu np kolejność pinów data, ani adresowych?

Dla SRAM zasadniczo kolejność linii adresowych i danych jest bez znaczenia. Natomiast dla SDRAM już kolejność ma znaczenie, ze względu na protokłół i polecenia konfiguracyjne przesyłane do tego typu pamięci. W pamięciach DRAM też kolejność linii adresowych może mieć znaczenie - kwestie odświeżania i poboru energii.

jacynka84 napisał:

Jedynie nie można do pinu ostatniego np A15 podać sygnału wyższego niż A15 co nie?

Możesz sobie tu przyporządkować adres np. A18, wtedy pamięć będzie widoczna w przestrzeni adresowej jako dwie połówki, rozdzielone nieużywanymi adresami. Będzie to wyglądać ciekawie, czasami nawet się stosuje (stosowało) takie zabiegi - np. pamięć stronnicowana, jeśli ilość pamięci przekracza limit wyznaczony przez przestrzeń adresową MCU.

Dzięki.
A czy 1 lacz na ALE1 ile teoretycznie opóźnia?
Nadal mnie męczy jaki jest na pewno pinout w trybie 4 portowym to nie jest dla mnie oczywiste. Macie jakiś link lub pewny opis? Mam jeden opis z datasheeta ale nic a nic nie jestem pewny, bo w jednej tabeli pisze np że tam gdzie jest w jednym ustawieniu normalnie CSn współdzielone z A16 i dalej, a na młodszych pinach nieużywane ALE1 i 2, i to by było całkowicie logiczne. Ale w innej tabeli która ma rzekomo służyć 4 portowemu podłączeniu jest już pomieszane.
Jedyne pewne ustawienie dla 4 portowego sramu nie jest nigdzie ściśle określone. A chodzi mi o piny adresów A16 i dalej i CSn, bo adresy A16 i 17 są niezależne i nagle w miejscu ALE 1 i 2 w 4 portowym ustawieniu a CSn dzieli adresy z pinami 18-21! Jest to tabela 27-4.

Oczywiście obecność zatrzasku wprowadza opóźnienie, co najmniej jednego taktu - tyle, że przy 64 MHz, jeden takt to pół cyklu zegarowego zegara rdzenia. Znowu, zakładając, że masz odpowiednio szybki zatrzask. Piny masz dokładnie opisane w nocie do XMEGA A1U, rev. F, w sekcji poświęconej EBI, oraz dodatkowo w tabelkach opisujących alternatywne funkcje pinów. Dodatkowo, część funkcji jest konfigurowalna i zależna od ustawień EBI, dlatego nigdzie nie znajdziesz opisu wszystkich możliwych kombinacji, bo to byłoby pewnie kilkanaście stron tabelek.
Także zdecyduj się najpierw na konkretny tryb połączenia z SRAM - LPC, z 1, lub 2 zatrzaskami, 3- lub 4-portowy, a potem przeczytaj odpowiednią sekcję i nastanie jasność. Timingi dla różnych trybów pracy masz też pokazane w nocie, łącznie z miejscami wstawiania ew. WSów.

@Marek_Skalski \Oczywiście masz rację i są kontrolery pracujące odpowiednio szybko, ale większość tych popularnych ma pewne ograniczenia.
Co do EBI. Popraw mnie jeśli się mylę odnośnie ARMa, ale jeśli interfejs pamięci bedzie taktowany z innego zegara niż rdzeń to i tak zajdzie konieczność synchronizacji, czyli coś na coś będzie musiało czekać.

Zauważyłem jeszcze coś zarówno w nocie jak i w bascomowym config xram, jest np 64K , 64 KB , address 16:23, ale od 16 do 23 liczy 8 bitów, a na adresowanie dla 65536 bajtów trzeba 16 bitów, czy to nie powinno być od adres 0?? O co tu chodzi bo nie kapuję
https://avrhelp.mcselec.com/index.html?adding_sram_4_port_non_multipl.htm

XMEGA może używać 24 bitowego adresu, czyli możesz zaadresować do 16 MB pamięci, stąd masz linie A0-A23. Oczywiście nie wszystkie musisz użyć. Sprawdź w nocie szczegóły, a nie bazuj na helpie do Bascoma.

Właśnie w nocie widać ze też est to jakby od najwyższego adresu liczone.