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 !!

do góry

W dniu 26.07.2014 22:21, s...@g...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.


--
pozdrawiam
MD

do góry

W dniu 26.07.2014 22:21, s...@g...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.
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.

--
pozdrawiam
MD

do góry

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.

>
> Jeśli połączenia są zgodne z zaleceniami to:
>
> 2. Spróbuj stworzyć plik mcs komendą z mojego sąsiedniego posta.

Jutro.

>
> 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ę.

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 ?!

do góry

W dniu sobota, 26 lipca 2014 22:30:11 UTC+2 użytkownik Mario napisał:
> W dniu 26.07.2014 22:21, s...@g...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.
>
>


Szalony pomysł, ino go cholera nie zrobię. Dlaczego? Ano dlatego, że mógłbym uwalić
przez to inne scalaki na pokładzie PCB. Jakieś 300$+. Ale tak czysto teoretycznie,
maskować *.bit na '0' lub '1' na kolejnych bitach. Wiem, wiem, jest to harcerska
metoda, tak nie powinno się robić, ja to rozumiem.. Efekty mogą być opłakane. Ale
kurde, korci mnie....

do góry

W dniu 26.07.2014 23:20, s...@g...com pisze:
> 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.

Wydaje się w porządku.


>>
>>
> 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 ?!

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


--
pozdrawiam
MD

do góry

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.

do góry

W dniu 2014-07-27 01:22, s...@g...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.

Pozdrawiam
MD

do góry

W dniu niedziela, 27 lipca 2014 01:26:48 UTC+2 użytkownik Mario napisał:
> W dniu 2014-07-27 01:22, s...@g...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 OK. Jeżeli tak,
to wiadomo do czego się przypie....ć. Ano do impacta, albo burdelu u mnie w kompie.
Jak dalej będzie to samo, to już brak pomysłów mnie ogarnia.

do góry

On Sun, 27 Jul 2014 02:18:47 -0700 (PDT), s...@g...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?

--
Marek

do góry