FPGA Altery bootujące się z szeregowego EPROM/FLASH

Pszemol snipped-for-privacy@polbox.com wrote: [...]

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.

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

Zasilanie jest niestety w porządku.

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

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

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

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

Zewnetrznej ? Od wiekow :-) Tj od ~15 lat, co w elektronice na jedno wychodzi :-)

Do pamieci programu dla tego procesora rozumiem ? A to ladowanie to tez przez procesorek programowo, czy "sprzetowo" przez fpga ?

A nie mozesz odczytac konfiguracji z fpga ? Albo porownac zawartosc flasha ?

Na pewno nie jest to problem wersji ? Moze ktos plyty podmienil ?

J.

No to super. Xilinxem nie bawiłem się nigdy... tu jest niemodny. Króluje w Stanach raczej Altera :-) Xilinx jest za drogi :-))

dobrze rozumiesz. zarówno bootloader (w ROM zakodowanym w FPG) jak i aplikacja z zewnętrznym RAM pracuje pod kontrolą CPU. Jest to zewnętrzna motorolka MC68EC000, 20MHz.

CPU. Jest to faza uruchamiania. Programista nie ma narzędzi do FPGA, więc ma przeze mnie zaprogramowany bootloader, który mu jego twórczość (512kb) ładuje do pamięci RAM.

Nie wiem czy mogę - wiem, że nie umiem... :-)

Nie, są tylko dwie bo tylko dwie płyty prototypowe zrobiłem... Osobiście się napociłem lutując ręcznie 2x FPGA Cyclone z 240 pinami :-)

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 ;-)

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.

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

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 ? :-)

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

A nie mozemy z tego wyciagnac wniosku ze kostka uszkodzona ?

J.

Jesteś już drugą osobą która twierdzi, że FPGA jest uszkodzone. Przedstawcie mi rozumowanie które Was prowadzi do tego wniosku...

Czy jeśli programuję TĄ SAMĄ KOSTKĘ z FPGA i działa poprawnie, to dlaczego miałoby się dziać cokolwiek inaczej gdy sczytuje info z flasha? Przecież tamta transmisja jest z checksumą itp...

A co jeszcze zostalo podejrzane ?

Ale flash jest dobry, sprawdzony :-) Wynikaloby z tego ze w kostce jest cos w srodku na tej transmisji uszkodzone :-)

Szkoda ze nie da sie fpga wymienic.

J.

Pszemol napisał(a):

Kiedy przekompilowujesz FPGA to jest ono układane (w sensie bramek i połączeń) inaczej niż poprzednio. Wynika to z algorytmów optymalizacji, które bazują na poszukiwaniu najlepszego rozmieszczenia i układu połączeń elementów. Metody te są skuteczne ponieważ bazują na sprawdzaniu przypadkowych rozwiązań. Jedną z takich metod jest np. symulowane wyżarzanie. Dlatego kompilacje tego samego projektu VHDL, zwłaszcza jeśli zawartość jest skomplikowana, dają różne rezultaty połączeń. Stąd też, być może, w nieszczęśliwym ułożeniu zaprutym we flashu fpga wykrzystuje uszkodzony rejestr/bramkę/obszar, a w innej kompilacji już nie.

?? Nie rozumiem... :-)

Ja trochę podejrzewam swój UART że pracuje coś niestabilnie... Na jednej kostce dobrze, na innej źle, po przekompilowaniu ze zmienionym Signal Tapem lepiej - nie mam pojęcia czego się czepić. Problem tylko z tą hipotezą jest taki, że on właściwie nie pracuje niestabilnie :-) On pracował na obu płytach, potem się zepsuł na jednej z nich :-) i już się nie naprawił... Nie jest to zwykłe uszkodzenie elektroniki na zewnątrz FPGA bo niby wszystko działa (jestem w stanie podmienić bootloader na inny program i używam UART - działa) ale jak puszczam strumień danych 500k ciurkiem to przestaje działać, jakby się zatykał... Wygląda to jakby rzeczywiście uszkodzenie było wewnątrz FPGA, ale jak się to mogło stać??? Kurcze - wystarczy załadować to samo FPGA programem przez JTAG i wszystko działa, nawet te 500k ze starym bootloaderem...

No jest.

Niby się da, ale tej którą wylutuję już nie bedę mógł wlutować spowrotem :-)) Nie jestem w stanie tak wylutować tej obudowy z 240-pinami aby się dała potem zalutować spowrotem - musiałbym użyć nowego FPGA. Kurde - czegoś tu nie rozumiem... muszę więcej pomyśleć ;-)

Tak jest. Zwłaszcza że w moim przypadku, projekt nie jest taki sam, bo zmieniałem połączenia "Signal Tap", czyli jest zypełnie inny projekt.

Hm... ale jak odróżnić "uszkodzony rejestr/bramkę" (dlaczego miałaby się uszkodzić jedna bramka WEWNĄTRZ układu?) od innych uszkodzeń? Czy te FPGA mają może jakiś program funkcjonalnego testera kazdej LE z osobna??

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 :-)

Umiesz - bylo cos jak asmi_read_sector() czy jakos tak :-) Potem tylko na RSa wyslac i zrobic compare.

ten w fpga znaczy sie ?

Ale przeciez ponoc wystarczy zaladowac zawartosc z jtaga a nie flasha i wszystko dziala ?

No widzisz sam wyciagasz ten wniosek :-)

A nie jest to kwestia temperatury ?

A to jest bardzo ciekawe pytanie. Nie bardzo potrafie sobie wyobrazic ..

Podgrzac, sama odpadnie :-)

J.

tak. jest ich tam 14 braci bliźniaków :-)

No niby tak.

Z tym, że ja przez "uszkodzenie" nie rozumiem koniecznie upalenia jakiejś bramki w FPGA, ale również błąd design w Quartusie. Już miałem taki problem, że w jednym miejscu pomyliłem się co do zboczy zegara którym wyzwalałem jedną rzecz i się skubaniec co jakiś czas narowił i generował znaki sam z siebie :-) Nie mam pojęcia czy czegoś podobnego nie zrobiłem gdzieś w innym miejscu :-)

W teorii - owszem... :-) W praktyce chyba nie będzie tak proste...

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.

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

Zobacz sobie

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.

Ale przeciez ponoc ten sam program dziala na drugiej kosci, oraz dziala na tejze kosci, o ile tylko inaczej wpisany.

J.