Z dziwnym działaniem FPGA po programowaniu z PROM: Co może być przyczyną?

No takich checów to jeszcze nie miałem... Temat jest kontynuacją wcześniejszego problemu dot. FTDI/FPGA, na chłopski rozum, guzik jedno z drugim ma coś wspólnego (w temacie konfiguracji logiki FPGA) , tymczasem łapy mnie opadają..

Podpinam się do JTAG'a (iMpact), odpalam Dziada i zgodnie z oczekiwaniem dostaję z automatu rozpoznany łańcuch połączeń:


TDI=>[FPGA(XC6SLX45)]=>[PROM(XCF16p)]=TDO


No i teraz mam 3 możliwości..

1) wstrzyknąć bitfajla od razu do FPGA
2) wygenerować fajla StachuChebel.mcs i zapisać dziada na dysku
3) Zaprogramować dziada Impactem (PROM)

No to zaczynamy teraz opis problemu. punkt po punkcie:

1) po zaprogramowaniu jest OK całość działa tak jak zaprojektowałem
2) Też nie ma problemu.
3) Też się programuje bez komunikatów o błędach i takich tam...

No i teraz zaczyna się jajco. Czegoś takiego jeszcze w życiu nie miałem. Bywało, że układ się nie chciał zaprogramować z PROM'a i wtedy totalna kicha, ale zawsze było to spowodowane jakimś tam bablokiem na PCB. Tymczasem teraz mam jajco takie, że FPGA zasysa dane z PROMA, jak gdyby z błędami. Po zaprogramowaniu FPGA JTAG'iem, całość działa perfekcyjnie, a po zaprogramowaniu z PROM'a tak nie do końca wszystkie funkcje działają. Sprawdzałem zgodność pliku *.mcs z zawartością PROM'a - jest OK.

POMOCY Koledzy, bo brak mi jakiejkolwiek koncepcji !!

No takich checów to jeszcze nie miałem... Temat jest kontynuacją wcześniejszego problemu dot. FTDI/FPGA, na chłopski rozum, guzik jedno z drugim ma coś wspólnego (w temacie konfiguracji logiki FPGA) , tymczasem łapy mnie opadają..

Podpinam się do JTAG'a (iMpact), odpalam Dziada i zgodnie z oczekiwaniem dostaję z automatu rozpoznany łańcuch połączeń:


TDI=>[FPGA(XC6SLX45)]=>[PROM(XCF16p)]=TDO


No i teraz mam 3 możliwości..

1) wstrzyknąć bitfajla od razu do FPGA
2) wygenerować fajla StachuChebel.mcs i zapisać dziada na dysku
3) Zaprogramować dziada Impactem (PROM)

No to zaczynamy teraz opis problemu. punkt po punkcie:

1) po zaprogramowaniu jest OK całość działa tak jak zaprojektowałem
2) Też nie ma problemu.
3) Też się programuje bez komunikatów o błędach i takich tam...

No i teraz zaczyna się jajco. Czegoś takiego jeszcze w życiu nie miałem. Bywało, że układ się nie chciał zaprogramować z PROM'a i wtedy totalna kicha, ale zawsze było to spowodowane jakimś tam bablokiem na PCB. Tymczasem teraz mam jajco takie, że FPGA zasysa dane z PROMA, jak gdyby z błędami. Po zaprogramowaniu FPGA JTAG'iem, całość działa perfekcyjnie, a po zaprogramowaniu z PROM'a tak nie do końca wszystkie funkcje działają. Sprawdzałem zgodność pliku *.mcs z zawartością PROM'a - jest OK.

POMOCY Koledzy, bo brak mi jakiejkolwiek koncepcji !!

W dniu sobota, 26 lipca 2014 22:41:57 UTC+2 użytkownik Mario napisał:



1. Wrzuć gdzieś schemat połączeń między XFC a XC6.


http://w396.wrzuta.pl/obraz/8BTIW4dipmw/schemacik

Połączenia CDAT[0..7] i wszelakie inne pierdulamenty idą tam gdzie trza.

To co piszesz ma sens. Też yak sobie pomyślałem, bo faktycznie miałem wcześniej wersję projektu, która właśnie tak się zachowywała. Jasna sprawa, ja tam coś niecoś spartoliłem. No ale teraz już próbowałem sztuczek Nowy_Projekt.bit=>StachuChebel.mcs ... Ciężko zauważyć jakiekolwiek podobieństwo pomiędzy nazwami plików i w związku z tym pomylić się.

Ale tak na marginesie, coś mi w łepetynie zaświtało!! Otóż mam pewne jajco z iMpactem już od pewnego czasu. W zasadzie olałem problem, być może zbyt pochopnie. Mianowicie, Korzystam z WebPacka v14.7 i jakakolwiek próba odpalenia impacta kończy się komunikatem o errorze (boszsz... te anglowulgaryzmy). Mam też na twardzielu v12.1, i stąd odpalam impacta. Może tu jest jajco? Nie wiem, brak mi pomysłu co dalej.

Hmmm..., a może jeszcze inaczej? A gdybym Ci tak podesłał *.bit, Ty byś przemielił to na *.mcs i odesłał? Byłbym b. wdzięczny. Chociaż diabli wiedzą jaki plik zasysa impact. Może przez nieuwagę wdupcyłem mu jakiegoś default'a ?!

1. Wrzuć gdzieś schemat połączeń między XFC a XC6.

Jeśli połączenia są zgodne z zaleceniami to:

2. Spróbuj stworzyć plik mcs komendą z mojego sąsiedniego posta.

3. Utwórz nową konfigurację w graficznym Impact prze skanowanie łańcucha

itd. Ewentualnie zaprogramuj w trybie konsolowym.

4. Musiałbyś ustalić czy "funkcje nie do końca działają" oznacza jakąś

poprzednią wersję, czy też nieobliczalne działanie wersji przed chwilą

skompilowanej. Może być, że do XC6 ładujesz nową wersję

StachuChebel.bit, a do XCF wrzucasz StachuChebel.mcs, który nie jest

zrobiony z tej wersji pliku bit. NA przykład z innego foldera. Sprawdź

sobie na przykład psując celowo projekt i plik bit i patrząc jaki efekt

po zaprogramowaniu PROMa.


To co piszesz ma sens. Też yak sobie pomyślałem, bo faktycznie miałem wcześniej wersję projektu, która właśnie tak się zachowywała. Jasna sprawa, ja tam coś niecoś spartoliłem. No ale teraz już próbowałem sztuczek Nowy_Projekt.bit=>StachuChebel.mcs ... Ciężko zauważyć jakiekolwiek podobieństwo pomiędzy nazwami plików i w związku z tym pomylić się.

W dniu niedziela, 27 lipca 2014 00:23:55 UTC+2 użytkownik Mario napisał:





Możesz sprawdzić który plik ładuje do PROMu. Najpierw zobacz czy widzi,

że się zmienił plik .bit. Gdy w trakcie kompilacji projektu masz otwarty

Impact, to przy próbie wykonania Generate File zgłosi ostrzeżenie, że

plik źródłowy zmienił się poza Impactem. To znaczy że widzi zmianę pliku

bit. Wygeneruj plik mcs. Odszukaj powstały plik mcs (po czasie

utworzenia) i usuń go. Jeśli mimo tego dasz radę wykonać Programm (z

Available Operations w tabie Impact Processes) dla twojego XCF16 to

znaczy, że sobie programujesz inną wersją pliku mcs.

Mogę oczywiście spróbować wykonać plik mcs, ale nie jestem pewien

efektu. Ja używam szeregowej pamięci xcf04 i do niej wystarczył

przełącznik -x xcf04s. Zakładam, że dla XCF16 wystarczy ustawić xcf16p

bo jest taki plik bsd, ale może trzeba podać dokładniej typ jak

xcf16p_1532 albo xcf16p_fs48. W sumie jest ze 6 plików bsd dla tej

pamięci. Poza tym program promgen ma wiele innych przełączników, ale

chyba głównie dla konfiguracji daisychain.

Wyśle ci maila na twoje konto gmailowe. Jeśli chcesz żebym stworzył plik

mcs to podeślij bit


OK, serdeczne dzięki. Jutro ( w zasadzie już dzisiaj) rano podeślę *.bit . Dzisiaj już padam na pysk, więc prysznic, piwko i do wyra .

Pozdrawiam, Stachu.

W dniu 26.07.2014 22:21, stchebel@gmail.com pisze:

No takich checów to jeszcze nie miałem... Temat jest kontynuacją wcześniejszego problemu dot. FTDI/FPGA, na chłopski rozum, guzik jedno z drugim ma coś wspólnego (w temacie konfiguracji logiki FPGA) , tymczasem łapy mnie opadają..



Podpinam się do JTAG'a (iMpact), odpalam Dziada i zgodnie z oczekiwaniem dostaję z automatu rozpoznany łańcuch połączeń:





TDI=>[FPGA(XC6SLX45)]=>[PROM(XCF16p)]=TDO





No i teraz mam 3 możliwości..



1) wstrzyknąć bitfajla od razu do FPGA

2) wygenerować fajla StachuChebel.mcs i zapisać dziada na dysku

3) Zaprogramować dziada Impactem (PROM)



No to zaczynamy teraz opis problemu. punkt po punkcie:



1) po zaprogramowaniu jest OK całość działa tak jak zaprojektowałem

2) Też nie ma problemu.

3) Też się programuje bez komunikatów o błędach i takich tam....



No i teraz zaczyna się jajco. Czegoś takiego jeszcze w życiu nie miałem. Bywało, że układ się nie chciał zaprogramować z PROM'a i wtedy totalna kicha, ale zawsze było to spowodowane jakimś tam bablokiem na PCB. Tymczasem teraz mam jajco takie, że FPGA zasysa dane z PROMA, jak gdyby z błędami. Po zaprogramowaniu FPGA JTAG'iem, całość działa perfekcyjnie, a po zaprogramowaniu z PROM'a tak nie do końca wszystkie funkcje działają. Sprawdzałem zgodność pliku *.mcs z zawartością PROM'a - jest OK.



POMOCY Koledzy, bo brak mi jakiejkolwiek koncepcji !!





1. Wrzuć gdzieś schemat połączeń między XFC a XC6.

2. Spróbuj stworzyć plik mcs komendą z mojego sąsiedniego posta.

Możesz sprawdzić który plik ładuje do PROMu. Najpierw zobacz czy widzi,

że się zmienił plik .bit. Gdy w trakcie kompilacji projektu masz otwarty

Impact, to przy próbie wykonania Generate File zgłosi ostrzeżenie, że

plik źródłowy zmienił się poza Impactem. To znaczy że widzi zmianę pliku

bit. Wygeneruj plik mcs. Odszukaj powstały plik mcs (po czasie

utworzenia) i usuń go. Jeśli mimo tego dasz radę wykonać Programm (z

Available Operations w tabie Impact Processes) dla twojego XCF16 to

znaczy, że sobie programujesz inną wersją pliku mcs.

Mogę oczywiście spróbować wykonać plik mcs, ale nie jestem pewien

efektu. Ja używam szeregowej pamięci xcf04 i do niej wystarczył

przełącznik -x xcf04s. Zakładam, że dla XCF16 wystarczy ustawić xcf16p

bo jest taki plik bsd, ale może trzeba podać dokładniej typ jak

xcf16p_1532 albo xcf16p_fs48. W sumie jest ze 6 plików bsd dla tej

pamięci. Poza tym program promgen ma wiele innych przełączników, ale

chyba głównie dla konfiguracji daisychain.

Wyśle ci maila na twoje konto gmailowe. Jeśli chcesz żebym stworzył plik

mcs to podeślij bit

W dniu 2014-07-27 01:22, stchebel@gmail.com pisze:

W dniu niedziela, 27 lipca 2014 00:23:55 UTC+2 użytkownik Mario napisał:











Możesz sprawdzić który plik ładuje do PROMu. Najpierw zobacz czy widzi,



że się zmienił plik .bit. Gdy w trakcie kompilacji projektu masz otwarty



Impact, to przy próbie wykonania Generate File zgłosi ostrzeżenie, że



plik źródłowy zmienił się poza Impactem. To znaczy że widzi zmianę pliku



bit. Wygeneruj plik mcs. Odszukaj powstały plik mcs (po czasie



utworzenia) i usuń go. Jeśli mimo tego dasz radę wykonać Programm (z



Available Operations w tabie Impact Processes) dla twojego XCF16 to



znaczy, że sobie programujesz inną wersją pliku mcs.



Mogę oczywiście spróbować wykonać plik mcs, ale nie jestem pewien



efektu. Ja używam szeregowej pamięci xcf04 i do niej wystarczył



przełącznik -x xcf04s. Zakładam, że dla XCF16 wystarczy ustawić xcf16p



bo jest taki plik bsd, ale może trzeba podać dokładniej typ jak



xcf16p_1532 albo xcf16p_fs48. W sumie jest ze 6 plików bsd dla tej



pamięci. Poza tym program promgen ma wiele innych przełączników, ale



chyba głównie dla konfiguracji daisychain.



Wyśle ci maila na twoje konto gmailowe. Jeśli chcesz żebym stworzył plik



mcs to podeślij bit





OK, serdeczne dzięki. Jutro ( w zasadzie już dzisiaj) rano podeślę *.bit . Dzisiaj już padam na pysk, więc prysznic, piwko i do wyra .



Pozdrawiam, Stachu.





Etam. Drink i CS GO.

Sruuuu !!.. Fajla wysłałem. Zobaczymy co z tego wyjdzie. Oby
wyszło =

W dniu niedziela, 27 lipca 2014 16:18:19 UTC+2 użytkownik Marek napisał:
On Sun, 27 Jul 2014 02:18:47 -0700 (PDT), stchebel@gmail.com wrote:

Sruuuu !!.. Fajla wysłałem. Zobaczymy co z tego wyjdzie. Oby

wyszło =



A tak z ciekawości- murarz zdradzić co ten projekt z FPGA ma robić? I

dlaczego na FPGA?


Tak po krótce, to ma odbierać dane 12-to bitowe z przetwornika A/C z częstotliwością 80MHz, robić w czasie rzeczywistym demodulację sygnału i cisnąć to przez USB do peceta.

On Sun, 27 Jul 2014 02:18:47 -0700 (PDT), stchebel@gmail.com wrote:

Sruuuu !!.. Fajla wysłałem. Zobaczymy co z tego wyjdzie. Oby

wyszło


A tak z ciekawości- murarz zdradzić co ten projekt z FPGA ma robić? I

dlaczego na FPGA?


Tak po krótce, to ma odbierać dane 12-to bitowe z przetwornika A/C z częstotliwością 80MHz, robić w czasie rzeczywistym demodulację sygnału i cisnąć to przez USB do peceta.

No takich checów to jeszcze nie miałem... Temat jest kontynuacją wcześniejszego problemu dot. FTDI/FPGA, na chłopski rozum, guzik jedno z drugim ma coś wspólnego (w temacie konfiguracji logiki FPGA) , tymczasem łapy mnie opadają..

Podpinam się do JTAG'a (iMpact), odpalam Dziada i zgodnie z oczekiwaniem dostaję z automatu rozpoznany łańcuch połączeń:


TDI=>[FPGA(XC6SLX45)]=>[PROM(XCF16p)]=TDO


No i teraz mam 3 możliwości..

1) wstrzyknąć bitfajla od razu do FPGA
2) wygenerować fajla StachuChebel.mcs i zapisać dziada na dysku
3) Zaprogramować dziada Impactem (PROM)

No to zaczynamy teraz opis problemu. punkt po punkcie:

1) po zaprogramowaniu jest OK całość działa tak jak zaprojektowałem
2) Też nie ma problemu.
3) Też się programuje bez komunikatów o błędach i takich tam...

No i teraz zaczyna się jajco. Czegoś takiego jeszcze w życiu nie miałem. Bywało, że układ się nie chciał zaprogramować z PROM'a i wtedy totalna kicha, ale zawsze było to spowodowane jakimś tam bablokiem na PCB. Tymczasem teraz mam jajco takie, że FPGA zasysa dane z PROMA, jak gdyby z błędami. Po zaprogramowaniu FPGA JTAG'iem, całość działa perfekcyjnie, a po zaprogramowaniu z PROM'a tak nie do końca wszystkie funkcje działają. Sprawdzałem zgodność pliku *.mcs z zawartością PROM'a - jest OK.

POMOCY Koledzy, bo brak mi jakiejkolwiek koncepcji !!

W dniu niedziela, 27 lipca 2014 20:41:16 UTC+2 użytkownik Mario napisał:
W dniu 27.07.2014 19:51, stchebel@gmail.com pisze:

W dniu niedziela, 27 lipca 2014 16:18:19 UTC+2 użytkownik Marek napisał:

On Sun, 27 Jul 2014 02:18:47 -0700 (PDT), stchebel@gmail.com wrote:



Sruuuu !!.. Fajla wysłałem. Zobaczymy co z tego wyjdzie. Oby



wyszło =







A tak z ciekawości- murarz zdradzić co ten projekt z FPGA ma robić? I



dlaczego na FPGA?





Tak po krótce, to ma odbierać dane 12-to bitowe z przetwornika A/C z częstotliwością 80MHz, robić w czasie rzeczywistym demodulację sygnału i cisnąć to przez USB do peceta.





To trochę tak jak w moim projekcie. Tylko ja na 50Ms/s. Ale inny target

więc nie jesteśmy konkurencją ATSD jaki przetwornik? Coś z serii LTC22xx?


AD9272

W dniu poniedziałek, 28 lipca 2014 00:34:58 UTC+2 użytkownik Adam Górski napisał:

Bo a to zasilanie gdzie� jeszcze nie wsta�o a to gdzie� inicjalizacja

nie przesz�a.

A mo�e sygna�y nie zsynchronizowane gdzie� zapodajesz.



Skutek mo�e by� w�a�nie taki �e idzie w krzaki.

Czy si� dobrze programuje to ju� chyba sprawdzi�e�.

Resztďż˝ koledzy juďż˝ napisali.


A jednak coś nie tak u mnie z impactem. Kolega Mario wygenerował mi mcs'a i wszystko jest OK.