Zjawisko zacinania UART w FPGA Altera Cyclone C6 przy bootowaniu z Flash

Tue Sep 21, 2004 3:48 pm   

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?

Tue Sep 21, 2004 4:48 pm   

"Jacek R. Radzikowski" <jacek@spamer.die.die.die.piranet.org> wrote in message news:cipndg$ks6$1@www.itl.waw.pl...
[quote:23c683d430]A probowales podmienic kostki flasha pomiedzy plytami?
[/quote:23c683d430]
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...

[quote:23c683d430]Patrzyles co sie dzieje na zasilaniu FPGA? Moze po zaladowaniu konfiguracji
wyskakuje jakas szpilka i zmienia sie zawartosc RAMu konfiguracyjnego?
[/quote:23c683d430]
Zasilanie jest niestety w porządku.

[quote:23c683d430]Analizatorem logicznym nic nie wykryles?
[/quote:23c683d430]
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ć...

[quote:23c683d430]Jak masz jakies wolne piny moze wyprowadz kilka sygnalow kontrolnych
z uarta zeby miec jakis wglad w stan automatu.
[/quote:23c683d430]
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ę.

[quote:23c683d430]Cudow nie ma. Musi byc jakas przyczyna
[/quote:23c683d430]
To wiem... już dawno nie wierzę w magię Tylko co jest tą przyczyną?

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

Tue Sep 21, 2004 6:12 pm   

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

Tue Sep 21, 2004 9:41 pm   

On Tue, 21 Sep 2004 11:48:59 -0500, Pszemol wrote:

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.

Tue Sep 21, 2004 11:42 pm   

"J.F." <jfox_nospam@poczta.onet.pl> wrote in message news:dis0l0t6c0kceuksqic89cmnn72quf9rpq@4ax.com...

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

Fri Sep 24, 2004 2:22 pm   

"Pszemol" <Pszemol@PolBox.com> wrote in message news:cip7uk.1ok.1@poczta.onet.pl...

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

Fri Sep 24, 2004 3:22 pm   

"Jacek R. Radzikowski" <jacek@spamer.die.die.die.piranet.org> wrote in message news:cj1fjq$cki$1@www.itl.waw.pl...

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

Fri Sep 24, 2004 3:48 pm   

On Fri, 24 Sep 2004 10:22:58 -0500, Pszemol wrote:

A nie mozemy z tego wyciagnac wniosku ze kostka uszkodzona ?

J.

Fri Sep 24, 2004 4:39 pm   

"J.F." <jfox_nospam@poczta.onet.pl> wrote in message news:noi8l09jlb0crp2kcu9dajocc83m5hb41m@4ax.com...

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

Fri Sep 24, 2004 4:48 pm   

Pszemol <Pszemol@polbox.com> wrote:

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.

Fri Sep 24, 2004 6:16 pm   

On Fri, 24 Sep 2004 12:39:29 -0500, Pszemol wrote:

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.

Fri Sep 24, 2004 7:06 pm   

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.

--
Pozdrawiam
Bartosz Sarama

Fri Sep 24, 2004 7:12 pm   

"J.F." <jfox_nospam@poczta.onet.pl> wrote in message news:8tp8l0l0122199r8ekdijia5oaffud1t17@4ax.com...

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

Fri Sep 24, 2004 7:54 pm   

"Bartosz Sarama" <qu_asi.mod@wp.pl> wrote in message news:cj1uot$449$1@panorama.wcss.wroc.pl...

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

Fri Sep 24, 2004 8:52 pm   

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


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