=?iso-8859-2?Q?FPGA_Altery_bootuj=B1ce_si=EA_z_szeregowego_EPROM/FLASH?=



Masz problem? Zapytaj na forum elektroda.pl

Poprzedni Następny
Wiadomość
Spis treści
From: "Pszemol" <Pszemol_at_nospam_PolBox.com>
Subject: =?iso-8859-2?Q?FPGA_Altery_bootuj=B1ce_si=EA_z_szeregowego_EPROM/FLASH?=
Date: Tue, 21 Sep 2004 11:48:59 -0500


Nie wiem czy popularniejszy w Polsce Xilinx robi tą samą technologię, ale
hipy Altery których używam, ładowane są przy każdym starcie zasilania
z pamięci EPROM/FLASH... Jeśli są tutaj użytkownicy układów FPGA wykonanych
w tej technologii to mam do Was pytanie o próbę wyjaśnienia następującego
zjawiska:

Zrobiliśmy dwie płyty prototypowe z kością altery Cyclone C6.
Kości normalnie ładują swoją konfigurację z szeregowego flasha.
Obie płyty były zaprogramowane taką samą zawartością: był tam
interfejs do zewnętrznej kostki procka motoroli, kilka UARTów,
interfejs do pamięci sram i flash dla programu itp... standard.

Płyta była zaprogramowana tak, że nie miała aplikacji w pamięci.
Miała tylko bootloader który miał za zadanie załadować aplikację
do pamięci sram (podtrzymywaną bateryjnie) i skoczyć do załadowanego
kodu po wykryciu dłuższej przerwy między znakami (około 3,5sekund).
Obie płyty działały elegancko przez chyba tydzień... Pewnego dnia,
mój kolega softwareowiec, który bawił się jedną z tych płyt
zgłosił mi problem, że płyta nie działa. Że przedwcześnie
zakończa ładowanie aplikacji (500kb ładowane 38400 baud).
Ponieważ druga płyta działała w porządku, podejrzewałem uszkodzenie
elektroniczne - mysłałem, że jakiś Maxim poszedł się kochać itp.
Nie. Elektronika jest w porządku. Wygląda to na to, że UART
wewnątrz FPGA się zacina po kilkunastu sekundach pracy i procek
z programem bootloadera nie widzi w pewnym momecie znaków, więc
przystępuje do uruchamienia w połowie ściągniętej aplikacji...
Próbowałem zaprogramować FPGA jeszcze raz, tym razem "na miękko",
czyli tylko przez JTAGa, nie zamazując tej podejrzanej zawartości
flasha, ale wszystko działa poprawnie za kazdym razem...

I teraz mam do Was pytanie - ki czort???!!! Jaki może być powód
dla którego płyta zmieniła swoją funkcjonalność po jakimś czasie?
Rozumiem, gdyby coś działało niestabilnie - sam napisałem ten
kod UARTa dla FPGA w VHDLu, więc nie mam do niego pełnego
zaufania :-) ale w końcu działał poprawnie i nagle się zepsuł?
I to nie zepsuł sie tak, ze czasem działa, czasem nie - po
prostu nie działa i już. Jednocześnie druga taka sama płyta działa
dobrze cały czas. Jednocześnie "zła" płyta zaprogramowana przez
JTAGa działa również dobrze... Nie ma możliwosci zniszczenia
bootloadera ze strony kodu - bootloader jest wprogramowany
wewnątrz FPGA w pamięć ROM... Co jest grane?? Ktoś ma pomysł
na wyjaśnienie tego zjawiska? Sama się zawartość flasha zmieniła?
Ale jak? Przecież jest chroniona cheksumą... Co jest grane?


========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!news.nask.pl!news.itl.waw.pl!not-for-mai

Poprzedni Następny
Wiadomość
Spis treści
From: "Jacek R. Radzikowski" <jacek_at_nospam_spamer.die.die.die.piranet.org>
Subject: Re: FPGA Altery =?ISO-8859-2?Q?bootuj=B1ce_si=EA?= z szeregowego EPROM/FLASH
Date: Tue, 21 Sep 2004 17:12:16 +0000 (UTC)


Pszemol <Pszemol_at_nospam_polbox.com> wrote:
[...]
wewnątrz FPGA w pamięć ROM... Co jest grane?? Ktoś ma pomysł
na wyjaśnienie tego zjawiska? Sama się zawartość flasha zmieniła?
Ale jak? Przecież jest chroniona cheksumą... Co jest grane?

A probowales podmienic kostki flasha pomiedzy plytami? Patrzyles
co sie dzieje na zasilaniu FPGA? Moze po zaladowaniu konfiguracji
wyskakuje jakas szpilka i zmienia sie zawartosc RAMu konfiguracyjnego?
Analizatorem logicznym nic nie wykryles?
Jak masz jakies wolne piny moze wyprowadz kilka sygnalow kontrolnych
z uarta zeby miec jakis wglad w stan automatu.
Cudow nie ma. Musi byc jakas przyczyna

j.



========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!news.onet.pl!not-for-mai

Poprzedni Następny
Wiadomość
Spis treści
From: "Pszemol" <Pszemol_at_nospam_PolBox.com>
Subject: =?iso-8859-2?Q?Re:_FPGA_Altery_bootuj=B1ce_si=EA_z_szeregowego_EPROM/FLASH?=
Date: Tue, 21 Sep 2004 12:48:20 -0500


"Jacek R. Radzikowski" <jacek_at_nospam_spamer.die.die.die.piranet.org> wrote in message news:cipndg$ks6$1_at_nospam_www.itl.waw.pl...
A probowales podmienic kostki flasha pomiedzy plytami?

Tego nie próbowałem- to byłby dobry test - dzięki za pomysł.
Gdyby po przełożeniu "złej" kostki do dobrej płyty dobra
płyta przestała działać to byłby to dowód że coś nie tak
z flashem...

Patrzyles co sie dzieje na zasilaniu FPGA? Moze po zaladowaniu konfiguracji
wyskakuje jakas szpilka i zmienia sie zawartosc RAMu konfiguracyjnego?

Zasilanie jest niestety w porządku.

Analizatorem logicznym nic nie wykryles?

Analizator logiczny niestety jest częścią projektu, to znaczy
aby zmienić miejsca przyczepienia analizatora należy przekompilować
układ... Próbowałem to zrobić i załadować do fpga bezpośrednio
przez JTAG (aby nie zniszczyć zawartości "złego" flasha) i nie
umiem powtórzyć problemu - zawsze działa dobrze, więc analizatorem
nic nie jestem w stanie wykryć...

Jak masz jakies wolne piny moze wyprowadz kilka sygnalow kontrolnych
z uarta zeby miec jakis wglad w stan automatu.

Do takich celów mam SignalTap - przez JTAG podglądać mogę każdy
sygnał, oczywiście są limity i nie wszystkie sygnały mogę oglądać
jednocześnie, więc potrzebna jest rekompilacja FPGA jak coś zmienię.

Cudow nie ma. Musi byc jakas przyczyna

To wiem... już dawno nie wierzę w magię :-) Tylko co jest tą przyczyną?

Spróbuję podmienić flasha i dam znać co się stało.


========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!news.onet.pl!not-for-mai

Poprzedni Następny
Wiadomość
Spis treści
From: "Pszemol" <Pszemol_at_nospam_PolBox.com>
Subject: =?iso-8859-2?Q?Re:_FPGA_Altery_bootuj=B1ce_si=EA_z_szeregowego_EPROM/FLASH?=
Date: Fri, 24 Sep 2004 10:22:58 -0500


"Pszemol" <Pszemol_at_nospam_PolBox.com> wrote in message news:cip7uk.1ok.1_at_nospam_poczta.onet.pl...
"Jacek R. Radzikowski" <jacek_at_nospam_spamer.die.die.die.piranet.org> wrote in message news:cipndg$ks6$1_at_nospam_www.itl.waw.pl...
A probowales podmienic kostki flasha pomiedzy plytami?

Tego nie próbowałem- to byłby dobry test - dzięki za pomysł.
Gdyby po przełożeniu "złej" kostki do dobrej płyty dobra
płyta przestała działać to byłby to dowód że coś nie tak
z flashem...

Zrobiłem ten test o którym pisałeś, Jacku - niestety, zła płyta
z flashem z dobrej pozostała zła. Dobra płyta z flashem ze złej
pozostała dobra... W sumie trudno się dziwić - w końcu zawartość
flasha gdyby się zmieniła bez powodu to byłoby to dosyć dziwne ;-)

Jak masz jakies wolne piny moze wyprowadz kilka sygnalow kontrolnych
z uarta zeby miec jakis wglad w stan automatu.

Do takich celów mam SignalTap - przez JTAG podglądać mogę każdy
sygnał, oczywiście są limity i nie wszystkie sygnały mogę oglądać
jednocześnie, więc potrzebna jest rekompilacja FPGA jak coś zmienię.

Co przekompiluję to system działa dobrze... jestem w stanie
odtworzyć problem tylko wtedy, gdy użyję starej konfiguracji
z flasha na tej własnie płycie... Co jest kuźwa grane?
Druga płyta z tym samym kodem działa dobrze cały czas...


========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!news.internetia.pl!mimuw.edu.pl!news.mimuw.edu.pl!uw.edu.pl!news.pw.edu.pl!news.itl.waw.pl!not-for-mai

Poprzedni Następny
Wiadomość
Spis treści
From: "Jacek R. Radzikowski" <jacek_at_nospam_spamer.die.die.die.piranet.org>
Subject: Re: FPGA Altery =?ISO-8859-2?Q?bootuj=B1ce_si=EA?= z szeregowego EPROM/FLASH
Date: Fri, 24 Sep 2004 15:48:10 +0000 (UTC)


Pszemol <Pszemol_at_nospam_polbox.com> wrote:
"Pszemol" <Pszemol_at_nospam_PolBox.com> wrote in message news:cip7uk.1ok.1_at_nospam_poczta.onet.pl...
"Jacek R. Radzikowski" <jacek_at_nospam_spamer.die.die.die.piranet.org> wrote in message news:cipndg$ks6$1_at_nospam_www.itl.waw.pl...
Jak masz jakies wolne piny moze wyprowadz kilka sygnalow kontrolnych
z uarta zeby miec jakis wglad w stan automatu.
Do takich celów mam SignalTap - przez JTAG podglądać mogę każdy
sygnał, oczywiście są limity i nie wszystkie sygnały mogę oglądać
jednocześnie, więc potrzebna jest rekompilacja FPGA jak coś zmienię.
Co przekompiluję to system działa dobrze... jestem w stanie
odtworzyć problem tylko wtedy, gdy użyję starej konfiguracji
z flasha na tej własnie płycie... Co jest kuźwa grane?
Druga płyta z tym samym kodem działa dobrze cały czas...

Jedyne co przychodzi mi do głowy to uwalona kostka albo płytka. Masz możliwość
zatrzymania automatu i sprawdzenia jego stanu w stanie "zawieszenia"?
W jakiej obudowie jest fpga? Może to jest jakiś zimny lut, który zaczyna
bruździć jak się układ nagrzeje? Jak masz taką możliwość to spróbuj przelutować
kostkę. Jak to nie pomoże, wymienić na nową (antystatyka!!!)
"Tę rurę musi dać się przepchać" :)

j.


========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!news.onet.pl!not-for-mai

Poprzedni Następny
Wiadomość
Spis treści
From: "Pszemol" <Pszemol_at_nospam_PolBox.com>
Subject: =?iso-8859-2?Q?Re:_FPGA_Altery_bootuj=B1ce_si=EA_z_szeregowego_EPROM/FLASH?=
Date: Fri, 24 Sep 2004 11:22:30 -0500


"Jacek R. Radzikowski" <jacek_at_nospam_spamer.die.die.die.piranet.org> wrote in message news:cj1fjq$cki$1_at_nospam_www.itl.waw.pl...
Jedyne co przychodzi mi do głowy to uwalona kostka albo płytka.

Nie bardzo rozumiem w jaki sposób miałoby to działać przy uwalonej
kostce jeśli zaprogramuję ją z JTAGa...

Masz możliwość zatrzymania automatu i sprawdzenia jego stanu w stanie "zawieszenia"?

Niestety nie. Nawet nie mam jak trigera ustawic na moment zaniku znakow...
Bo co ustawie? Jak ustawic "RXINT nie sygnalizuje przez N milisekund" w Signal Tap ? :-)

W jakiej obudowie jest fpga? Może to jest jakiś zimny lut, który zaczyna
bruździć jak się układ nagrzeje? Jak masz taką możliwość to spróbuj przelutować
kostkę. Jak to nie pomoże, wymienić na nową (antystatyka!!!)
"Tę rurę musi dać się przepchać" :)

Obudowa jest PQFP 240 pin - względnie łatwo daje się to wlutować/wylutować ręcznie.
Jednak nie przekonuje mnie do diagnozy "uwalona kostka" fakt, że układ działa
w 100% poprawnie gdy jest zaprogramowany nowym kodem... Nie rozumiem tego...


========
Path: news-archive.icm.edu.pl!news2.icm.edu.pl!news.itl.waw.pl!not-for-mai

Poprzedni Następny
Wiadomość
Spis treści
From: "Jacek R. Radzikowski" <jacek_at_nospam_spamer.die.die.die.piranet.org>
Subject: Re: FPGA Altery =?ISO-8859-2?Q?bootuj=B1ce_si=EA?= z szeregowego EPROM/FLASH
Date: Sat, 25 Sep 2004 04:45:43 +0000 (UTC)


Pszemol <Pszemol_at_nospam_polbox.com> wrote:
"Jacek R. Radzikowski" <jacek_at_nospam_spamer.die.die.die.piranet.org> wrote in message news:cj1fjq$cki$1_at_nospam_www.itl.waw.pl...
Jedyne co przychodzi mi do głowy to uwalona kostka albo płytka.
Nie bardzo rozumiem w jaki sposób miałoby to działać przy uwalonej
kostce jeśli zaprogramuję ją z JTAGa...

Może być uszkodzony fragment odpowiedzialny za ładowanie bitstreamu z flasha.
Odczytuje dobrze, weryfikuje sygnaturę (a może nie? Może nastepować jakieś
przekłamanie a uklad kontoli go nie wykrywa?), przekłamanie następuje podczas
wpisywania do RAMu konfiguracyjnego. Programowanie przez JTAG omija uszkodzony
fragment i układ programuje się poprawnie.

Masz możliwość zatrzymania automatu i sprawdzenia jego stanu w stanie "zawieszenia"?
Niestety nie. Nawet nie mam jak trigera ustawic na moment zaniku znakow...
Bo co ustawie? Jak ustawic "RXINT nie sygnalizuje przez N milisekund" w Signal Tap ? :-)

A możesz wykryć że układ się "zawiesza"? Wtedy "zamroź" stan układu i sprawdź
JTAGiem w jakim stanie znajduje się układ.

W jakiej obudowie jest fpga? Może to jest jakiś zimny lut, który zaczyna
bruździć jak się układ nagrzeje? Jak masz taką możliwość to spróbuj przelutować
kostkę. Jak to nie pomoże, wymienić na nową (antystatyka!!!)
"Tę rurę musi dać się przepchać" :)
Obudowa jest PQFP 240 pin - względnie łatwo daje się to wlutować/wylutować ręcznie.
Jednak nie przekonuje mnie do diagnozy "uwalona kostka" fakt, że układ działa
w 100% poprawnie gdy jest zaprogramowany nowym kodem... Nie rozumiem tego...

Zobacz sobie http://groups.google.com/groups?selm=40ed17d9%241%40news.home.net.pl.
Kostka nie musi być martwa żeby być uszkodzoną. Ładunki elektrostatyczne mogły uszkodzić
ją "częściowo" i układ działa, ale nie do końca.
Jeśli zawartość flasha jest w porządku, układ i płytka są poprawnie zaprojektowane,
obszar poszukiwań zawęża sie do wykonania płytki i samej kostki FPGA.
Dobrze by było porównać rzeczywiste konfiguracje obu kostek: dzałającej i sprawiającej
kłopoty. Masz możliwosc odczytania jej w trakcie pracy?

pzdr.
j.



========
Path: news-archive.icm.edu.pl!news2.icm.edu.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai

Poprzedni Następny
Wiadomość
Spis treści
From: jerry1111 <stop_this_spam_jerry1111_remove_at_nospam_remove.wp.pl>
Subject: Re: =?ISO-8859-2?Q?FPGA_Altery_bootuj=B1?=
Date: Fri, 24 Sep 2004 23:52:00 +0200


On Fri, 24 Sep 2004 10:22:58 -0500, "Pszemol" <Pszemol_at_nospam_PolBox.com>
wrote:

Co przekompiluję to system działa dobrze... jestem w stanie
odtworzyć problem tylko wtedy, gdy użyję starej konfiguracji
z flasha na tej własnie płycie... Co jest kuźwa grane?
Druga płyta z tym samym kodem działa dobrze cały czas...

Mialem kiedys podobny problem. Okazalo sie, ze wina lezala po stronie
asynchronicznego resetu ;-)) (no... malo wtedy wiedzialem o FPGA).

Objawialo sie 3.14*drzwi raz na tydzien.

Chociaz u Ciebie pewnie jest 'reset delay' - bo w Niosie2 widzialem
ze spece z Altery juz to wstawiaja, a ze mna sie klocili 2 lata temu
ze to niepotrzebne :-)


--
Jerry

========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!news.onet.pl!not-for-mai

Poprzedni Następny
Wiadomość
Spis treści
From: "Pszemol" <Pszemol_at_nospam_PolBox.com>
Subject: =?iso-8859-2?Q?Re:_FPGA_Altery_bootuj=B1ce_si=EA_z_szeregowego_EPROM/FLASH?=
Date: Sun, 26 Sep 2004 16:13:48 -0500


"jerry1111" <stop_this_spam_jerry1111_remove_at_nospam_remove.wp.pl> wrote in message news:r839l0puu23iijomguu2q0qs24ot6e967d_at_nospam_4ax.com...
Co przekompiluję to system działa dobrze... jestem w stanie
odtworzyć problem tylko wtedy, gdy użyję starej konfiguracji
z flasha na tej własnie płycie... Co jest kuźwa grane?
Druga płyta z tym samym kodem działa dobrze cały czas...

Mialem kiedys podobny problem. Okazalo sie, ze wina lezala po stronie
asynchronicznego resetu ;-)) (no... malo wtedy wiedzialem o FPGA).

Powiedz coś więcej na ten temat...

Objawialo sie 3.14*drzwi raz na tydzien.

Chociaz u Ciebie pewnie jest 'reset delay' - bo w Niosie2 widzialem
ze spece z Altery juz to wstawiaja, a ze mna sie klocili 2 lata temu
ze to niepotrzebne :-)

Akurat problem opisywany w tym wątku to inny projekt, bez niosa.
Te akurat projekt wykorzystuje procek motoroli MC68SEC000.


========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!newsfeed.atman.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai

Poprzedni Następny
Wiadomość
Spis treści
From: jerry1111 <stop_this_spam_jerry1111_remove_at_nospam_remove.wp.pl>
Subject: Re: =?ISO-8859-2?Q?FPGA_Altery_bootuj=B1?=
Date: Mon, 27 Sep 2004 11:59:57 +0200


On Sun, 26 Sep 2004 16:13:48 -0500, "Pszemol" <Pszemol_at_nospam_PolBox.com>
wrote:

Mialem kiedys podobny problem. Okazalo sie, ze wina lezala po stronie
asynchronicznego resetu ;-)) (no... malo wtedy wiedzialem o FPGA).

Powiedz coś więcej na ten temat...

W przykladowych designach z Niosem2 masz pin resetu podlaczony
do procka przez taki uklad 'reset delay' czy podobnie sie nazywajacy.
Glownie chodzi o to, ze przychodzacy impuls resetu jest asynchroniczny
przyjdzie np: 1ns przed tym zboczem to czesc DFFow sie zresetuje, a
czesc ma prawo nie zdazyc :-)
Dlatego trza ten reset przeformowac na synchroniczny z naszym
zegarkiem.

Objawialo sie 3.14*drzwi raz na tydzien.

Chociaz u Ciebie pewnie jest 'reset delay' - bo w Niosie2 widzialem
ze spece z Altery juz to wstawiaja, a ze mna sie klocili 2 lata temu
ze to niepotrzebne :-)

Akurat problem opisywany w tym wątku to inny projekt, bez niosa.
Te akurat projekt wykorzystuje procek motoroli MC68SEC000.

To nic - masz tam reset?


--
Jerry

========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!news.onet.pl!not-for-mai

Poprzedni Następny
Wiadomość
Spis treści
From: "Pszemol" <Pszemol_at_nospam_PolBox.com>
Subject: =?iso-8859-2?Q?Re:_FPGA_Altery_bootuj=B1ce_si=EA_z_szeregowego_EPROM/FLASH?=
Date: Mon, 27 Sep 2004 08:51:29 -0500


"jerry1111" <stop_this_spam_jerry1111_remove_at_nospam_remove.wp.pl> wrote in message news:eqffl09q929d6aeofe0vibitd55q56j56u_at_nospam_4ax.com...
W przykladowych designach z Niosem2 masz pin resetu podlaczony
do procka przez taki uklad 'reset delay' czy podobnie sie nazywajacy.
Glownie chodzi o to, ze przychodzacy impuls resetu jest asynchroniczny
- czyli jak mamy uklad reagujacy na narastajace zbocze i reset
przyjdzie np: 1ns przed tym zboczem to czesc DFFow sie zresetuje, a
czesc ma prawo nie zdazyc :-)
Dlatego trza ten reset przeformowac na synchroniczny z naszym
zegarkiem.

Ciekawe, ciekawe... dlaczego ma prawo nie zdążyć?
Nie wiedziałem, że są takie ograniczenia dla asynchronicznego "clear".
Musiałem nieuważać kiedyś na lekcjach z cyfrówki ;-)

Akurat problem opisywany w tym wątku to inny projekt, bez niosa.
Te akurat projekt wykorzystuje procek motoroli MC68SEC000.

To nic - masz tam reset?

No reset wchodzi do układu i resetuje wiele przerzutników, fakt...


========
Path: news-archive.icm.edu.pl!newsfeed.gazeta.pl!newsfeed.tpinternet.pl!atlantis.news.tpi.pl!news.tpi.pl!not-for-mai