Problem z odczytem przez FT2232H w trybie FT245 FIFO synchroniczny

Witam,

Mam na pokładzie swojej PCB, FT2232H i FPGA. Zapis z PC do FPGA w trybie synchronicznym działa OK, natomiast mam jajca przy odczycie z FPGA do PC.

Najpierw hardware w FPGA. Wygląda to mniej więcej tak:

USB_CLK: in std_logic; RST : in std_logic; TXE_n : in std_logic; WR_n : out std_logic; USB_DATA: inout std_logic_vector(7 downto 0); RAM_DATA: in std_logic_vector(7 downto 0); RD_ADDR: out std_logic_vector(12 downto 0);

signal RD_ADDRs: std_logic_vector(12 downto 0);

process (USB_CLK,RST,TXE_n) begin if RST='1' then RD_ADDRs<=(others=>'0'); RD_ADDR<=(others=>'0'); USB_DATA<=(others=>'Z'); WR_n<='1'; else if USB_CLK'event and USB_CLK='1' then WR_n<=TXE_n; if TXE='0' then USB_DATA<=RAM_DATA; RD_ADDRs<=RD_ADDRs+1; RD_ADDR<=RD_ADDRs; else USB_DATA<=(others=>'Z'); end if; end if; end if; end process;

=========

I teraz software (Delphi):

ResetAddressCounters; ftresult:=FT_Read(FT_HANDLE,@FT_In_Buffer,8192,@Read_Result);

Załóżmy, że chcę odczytać RAM zaimplementowany w FPGA. Zawartość RAM'u:

0,1,2,3...255,0,1,2....255,....,.... - razem 8kB (taka 32-zębna piła)

Przy pierwszym odczycie zawartość FT_In_Buffer jest cholera jakby zrotowana w prawo o losową ilość adresów. Np. o trzy adresy, w wyniku czego odczytuję:

253,254,255,0,1,2,3....255,0,1,2....255,0,1,2....252

Każdy kolejny odczyt powoduje rotację w prawo o dokładnie 16 bajtów.

Jakieś porady?

Reply to
stchebel
Loading thread data ...

W dniu 2014-07-01 14:06, snipped-for-privacy@gmail.com pisze:

Wyczścić fifo przed użyciem ? Ustawić RD_ADDR na początek po pierwszym odczycie. Jak z poziomu pc ustawiasz RD_ADDRES na początek ? Jaka jest idea synchronizacji ?

Pzdr

Adam

Reply to
Adam Górski

W dniu wtorek, 1 lipca 2014 23:08:48 UTC+2 użytkownik Adam Górski napisał:

Też o tym myślałem. Problem w tym, że w drajverach D2XX od FTDI brak takiej funkcji.

Dokładnie!! Przed każdym rozpoczęciem odczytu daję impuls RST, który asynchronicznie zeruje licznik RD_ADDR (popatrz na kod VHDL). Impuls RST generuję programowo, działa poprawnie, sprawdziłem na oscylu. Synchronizacja jest banalnie prosta. Leci akwizycja danych do bufora w pamięci FPGA i sprawdzam bit statusu akwizycji. Jak akwizycja zakończona, to walę 2 komendy opisane w pierwszym poście. Aha!! Robiłem eksperymenty i tak np. przy odczycie tylko 512 bajtów z bufora, każdorazowo robi mi rotację o jeden bajt. Podejrzewam, że coś jest nawalone w drajverach D2XX, albo pieron wie co ?!

Reply to
stchebel

W dniu 2014-07-02 01:04, snipped-for-privacy@gmail.com pisze:

Ok. Jaka to fpga ? Na pewno są tam jakieś mechanizmy dostępu przez jtaga : podgląd ram-u , podgląd sygnałów itd czy nawet rejestratory z wyzwalaniem.

  1. Czy jesteś pewien zawartości pamięci - ale tak na 10000%? Czyli np rom ze wzorcem. Napisałeś że jest tam jakiś ram, ale może być dwuportowy lub inna cholera.
  2. Może być też tak że w momencie rozpoczęcia przesyłania FT czyści sobie fifo ,wiec należałoby wpisać do fifo dopiero jak zacznie się odczyt po pc stronie. Na pewno jest to w sheecie opisane.
  3. Szukałeś jakiś app note, white papers etc ?

VHDL nie wygląda źle, może ja bym go zrobił całkowicie synchronicznie, albo przynajmniej synchronizował RST do zegara USB_CLK ( albo oba powyższe ). Nie widzę reszty wiec nic więcej nie powiem.

Pzdr.

Adam Górski

Reply to
Adam Górski

W dniu środa, 2 lipca 2014 12:48:40 UTC+2 użytkownik Adam Górski napisał:

XC6SLX45

Pierwsze co zrobiłem, jak zobaczyłem jak się to pieprzy, wstawiłem rom'a ze wzorce 32-zębnej piły (32kB). To samo. Mało tego, zrobiłem też próbę wstawiając adres RD_ADDR jako dane do odczytu. To samo...

To powinno być pilnowane przez drajvery D2XX, a one są jakie są. Nie mam na to wpływu.

Jasne, że tak.

formatting link

Szkoda:{

Reply to
stchebel

W dniu środa, 2 lipca 2014 13:15:11 UTC+2 użytkownik snipped-for-privacy@gmail.com napisał:

============

Wygląda na to, że nie ja jeden mam ten problem.

formatting link

Reply to
stchebel

W dniu środa, 2 lipca 2014 12:48:40 UTC+2 użytkownik Adam Górski napisał:

Popatrz na kolejne moje wpisy.. Na 99.99% obstawiam na spaprane drjwery przez producenta, A producent.. , normalka, jak "application engineer" nie wie o co biega, to za Wuja Wacka nie odpowiada na emaile. Krótko mówiąc, support techniczny FTDI nie istnieje, albo ma to w d.... Ponieważ nie znam przyczyny. a tylko skutki, więc zastosowałem "leczenie objawowe". Najsampierw puszczam z ROM'u wzorzec, łapię jego przesunięcie adresowe, a następnie przy każdym kolejnym "frame"'ie danych robię przesunięcie o 16 bajtów. No i to działa. Niestety jest to zrobione metodą empiryczną, zostały wyleczone objawy, lecz nie przyczyny. Nie podoba mi się to moje rozwiązanie, ale póki co jest skuteczne i muszę z tym żyć...

Reply to
stchebel

W dniu 2014-07-02 13:25, snipped-for-privacy@gmail.com pisze:

Zapodaj proszę swój kod inicializujący FT2232H w delphi.

Adam

Reply to
Adam Górski

W dniu 2014-07-02 21:27, snipped-for-privacy@gmail.com pisze:

Rozwiązanie o którym piszesz ma króciutkie nóżki. Co będzie jak w/w bug zostanie naprawiony ? ( O ile to jest bug ).

Jeżeli to komercyjne lub przemysłowe lub inne niż amatorskie, to jest to rozwiązanie nie do przyjęcia. Tak naprawdę , nie wiadomo co powoduje przesunięcie o te 16 bajtów.

  1. Trzeba gnębić dystrybutora o dojście do ludzi którzy mogą mieć pojęcie o w/w problemie.
  2. Jeżeli app engineer nie ma pojęcia - domagać się pchnięcia sprawy wyżej.

Zrób jeszcze proszę jeden test:

  1. Uruchom program odbierający na PC - niech sobie czeka na dane
  2. Dane do fifo z fpga zacznij wpisywać dopiero po 2 - 3 sekundach tak żeby połączenie z pc zostało zainicjowane zanim dodasz jakiekolwiek dane do fifo.

Daj znać co wyszło

Pzdr

Adam

Reply to
Adam Górski

Nie sądzę, że problem jest po stronie producenta, Mój klient stosuję ten układ w pewnym urządzeniu od dłuższego czasu w większych ilościach i nie słyszałem ani razu o takim problemie, ale fakt nie znam jego konfiguracji.

Mister

Reply to
MiSter

W dniu 2014-07-02 21:27, snipped-for-privacy@gmail.com pisze:

Jakiś progres ?

Adam

Reply to
Adam Górski

W dniu poniedziałek, 7 lipca 2014 14:20:39 UTC+2 użytkownik Adam Górski napisał:

Witaj Adam,

No w końcu coś 'do przodu' !! W końcu ten fragment projektu zaczął fungować. No i teraz gdzie był problem, i jak został rozwiązany? Otóż problem jest nie w błędnej dokumentacji FTDI, lecz w jej niekompletności. FTDI zarówno w opisie HW jak i SW nic nie wspomina o przypadkach 'odaktywnienia' sygnału TXE# podczas softwarowej transakcji FT_Read. I tu jest jajco!! Stąd nie ja pierwszy i chyba nie ostatni wydałem z siebie tyle wulgaryzmów do monitora podczas prototypienia tak wydawałoby się badziewnego tematu. Aż w końcu mój syn znalazł coś takiego:

formatting link

Skorzystałem z Fig.17, Fig.22, Fig.8. + objaśnienia + przebiegi czasowe jako wzorzec do symulacji. W/g powyższego zrobiłem to na FSM edytorze (Aldec ewaluacyjny), przetłumaczył mi to na VHDL, symulacja i takie tam, ..w końcu działa !! Aha!! W/w malunki (8,22) są nasmarowane w/g konwencji ASM. (Algorythmic State Machine). Nie mylić z czystym FSM. Trochę mnie to na sam początek poirytowało, ale już wiem o co chodzi.

Jeżeli ktokolwiek z grupy potrzebuje gotowego kodu TX/RX w VHDL'u na komunikację w trybie sync. FIFO dla FT2232H/FPGA, proszę dać znać.

Pzdr,

*.Sch

P.S. A coby nie było tak sielankowo, to wyskoczył inny problem , przy którym ZGŁÓPIAŁEM !! No ale, jest to temat na inny wątek.. Jutro to opiszę w szczegółach.

Reply to
stchebel

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.