Typowe przyczyny nadmiernego grzania się układów p

Dnia Thu, 7 Jun 2018 21:14:27 -0500, Pszemol napisał(a):

Kiedys mnie dopadlo, wlasnie w RAM, na szczescie na etapie prototypu

Dlugie przewody zasilajace + brak kondensatora na plytce i sie zrobilo.

Ha, ciekawe "High-power microwave interference can also trigger latch ups." A teraz wifi, komorki ... dlugie kable do tego LCD ?

USA - przeswietlenie dentystyczne pewnie drogie ... a i tak watpie czy pokaze. Trzeba by obudowe rozpuscic ...

J.

W dniu 08.06.2018 o 04:14, Pszemol pisze:

LCD jest z dotykiem czy bez?

1. Pogadać z klientem w jakich warunkach to pracuje i na co jest narażone. Może kojarzy w jakim momencie pada?
2. Zrobić porządnie badania nie tylko ESD, ale też burst, surge, narażenia na częstotliwości radiowe (przewodzone i promieniowane).

W dniu 2018-06-08 o 04:14, Pszemol pisze:

Co sprawdzić nie wiem. Nigdy też nie projektowałem tak szybkich urządzeń, ani procka z zewnętrznym RAM.

Kiedyś wyczytałem że połączenie 1 do 1 wyjścia z wejściem cyfrówki, gdzie są bardzo duże dU/dt powoduje, że na wejściu pojawiają się przepięcia poza przedział napięć zasilania. Kondensatory na VCC nie pomogą bo to chodzi o spadki na wewnętrznych podłączeniach struktury do pinów VCC i GND. Te przepięcia są tłumione diodami zabezpieczającymi. Nie wiem, może diody podlegają stopniowej degradacji. Takie przepięcie wywołując impuls prądu w takiej diodzie ponad ileś tam być może może doprowadzić do latch-up.

W takie linie podobno powinno się wkładać rezystory (rzędu 47..100) w szereg. P.G.

Bez dotyku.

Obudowa aluminiowa, uziemiona - dziura z przodu na 7" LCD. W pudle osobny moduł zasilacza 12V, na płytce procesora regulatory 5V i 3V3. Zamontowana całość na zewnątrz budynku. Klawiatura podłączona do przedniej ściany, pod LCD, wchodzi na płytkę zabezpieczona transorbami 5V, odseparowana od CPU przez sterownik klawiatury I2C. Komunikacja ze światem zewnętrznym przez RS485, również odseparowana od CPU przez driver linii RS485 - nie rozumiem w jaki sposób warunki użytkowania mogły spowodować uszkodzenie scalaka procka czy pamięci SDRAM na płytce.

W jaki sposób wytłumaczysz uszkodzenie procesora przez narażenia na częstotliwości radiowe gdy jest na płytce w uziemioniej obudowie aluminiowej?

Pszemol wrote on 08.06.2018 20:38:

Nikt ci tego dokładnie nie powie nie widząc urządzenia, layoutów płytki, sposobów podłączenia zasilania, interfejsów itp. Macie w tej swojej firmie speca od EMC? To niech się zajmie tematem. A jak szukasz pomocy na grupie, to chociaż pokaż z czym mamy do czynienia. Bo inaczej dostaniesz tylko zestaw ogólnych porad.

Zakładając, że te elementy nie są z jakiejś wadliwej parti, albo nie są podróbkami, to jest szansa że procek i sdram są najbardziej podatnymi elementami na drodze zakłóceń (bo są wykonane w najmniejszym procesie technologicznym). Trzeba przeanalizować jakie masz drogi którymi "coś" może wejść i potem wyjść.

Jakie masz linie wchodzące do urządzenia? Zasilanie, RS485, coś jeszcze? RS485 ma izolację galwaniczną? Jak te linie są zabepieczone przed przepięciami? Czy jak na liniach zasilających dostaniesz "strzał" common mode, to jedyną drugą ucieczki nie stają się linie RS-485 i po drodze nie znajduje się akurat procek? Albo w drugą stronę (RS485->uC->zasilanie).

A może zasilanie procka nie jest wystarczająco zabezpieczone i przy zakłóceniach dostaje jakieś szpile?

W twojej obudowie jest dziura na wyświetlacza a wyświetlacz LCD to kupa elektrod napylonych na szkło. Te elektrody w zależności od częstotliwości mogą być gorszymi lub lepszymi antenami. W czasie testów odporności na radiówkę promieniowaną ustawia się natężnie pola 3V/m dla sprzętu domowego i 10V/m dla warunków przemysłowych. Być może są to poziomy wystarczające, żeby zakółcić pracę urządzenia. Czy mogą spowodować uszkodzenie? Chyba nie, ale skąd możesz wiedzieć bez testów?

Myślisz wciąż, że to EMC/EMI ? Urządzenie przeszło odpowiednie testy.

No też tak rozumuję, ale w dalszych analizach znalazłem kilka płytek uszkodzonych w sposób nie wywołujący grzania układów, choć wciąż procek lub pamięć SDRAM były uszkodzone.

Na przykład na jednej z płytek linia adresowa A10 była zwarta z masą - podniosłem nóżkę procesora i zwarcie jest wewnątrz procka...

Na innej płytce widać linie danych walczą ze sobą, charakterystyczne schodki napięć pomiędzy 0 a 3V3 - podniosłem nogę D31 pamięci SDRAM i sygnał na procku jest teraz właściwy, noga D30 podniesiona SDRAM wisi na jakimś dziwnym poziomie 2.5V - czyli jakieś wewnętrzne uszkodzenie scalaka SDRAM.

W obu przypadkach opisanych wyżej sam CPU działa poprawnie i kod nieużywający zewnętrznej szyny pamięci działa bardzo dobrze, czyli uszkodzenia ograniczone do wyjść/wejść związanych z pamięciami zewnętrznymi.

Jest RS485 izolowane (ADM2587, LC03-6 i bezpieczniki TRF600-150-RB).

Zasilacz dwustopniowy: najpierw z sieciówki robi się 12V, potem z tych 12VDC idzie do impuslowego małej mocy dającego 3.3V dla cpu. W pierony kondziorów 0.1uF dookoła proca, pamięci i na całej płytce.

Chyba dla przemysłówki robią testy 6V/m i urządzenie przeszło takie testy. Również strzelaliśmy w szybę LCD pistoletem ESD: nie rusza go 20kV. Nie udało się nam wywołać tego typu efektów uszkodzenia w labie...

W dniu 18.06.2018 o 03:43, Pszemol pisze:

Przy tak skąpych danych można tylko zgadywać. Ale skoro uszkodzenie pojawia się u jednego klienta a u innych, do których trafiły urządzenia z tej samej partii nie, to chyba jest to dobry trop?

Kondensatory to nie jest zabezpieczenie przed udarami. Miałem raczej na myśli coś co może rozproszyć energię zakłóceń (warystory, transile itp.)

Dlatego pytałem cię o warunki pracy u klienta. Może ma tam jakiś sprzęt, który może generować śmieci? Duże silniki, spawarki, falowniki?

W dniu 2018-06-18 o 09:17, Zbych pisze:

Dawno, dawno temu, jeszcze w ubiegłym wieku, jak mi się wydawało, że jak driver RS485 jest 16kV ESD protected to jest odporny na wszystko mieliśmy taki przypadek, że na około 100 instalacji po całej Polsce tylko w jednej systematycznie urządzenia się blokowały. Po wyłącz/włącz działały normalnie. Uzgodniłem, żeby przy następnej takiej sytuacji nie resetowali tylko wezwali. Udało mi się bez wyłączania zasilania rozebrać urządzenie. Stwierdziłem, że VCC zamiast 5V miało około 2V i 78L05 (stabilizacja z

12V) był gorący. Mierząc spadki napięć na GND ustaliłem który element ciągnie prąd. Przyczyną był latch-up. 78L05 nie miał w ogóle chłodzenia i dzięki temu termicznie ograniczał prąd do na tyle małej wartości, że pin z latchup-em się nie palił doszczętnie i reset pomagał.

Ta instalacja była zainstalowana w wyjątkowym terenie - na najwyższym punkcie względnie rozległego płaskowyżu. Co okres burz to w te budynki waliły pioruny seriami, ale i tak blokowanie zdarzało się typowo raz na sezon burzowy. P.G.

Jeżeli nie RF/EMC/EMI to sprawdź pod kontem temperatury w miejscu gdzie pracowało.

Świeciło na nią słońce ? Klimatyzowany lab ? Jak zasilane ? Zasilacz gdzie ? Część jakiejś maszyny ? Jakieś elementy wykonawcze ? Czego nie było na testach ESD ? Podłączone PE do obudowy ? Jakieś szybkie zmiany w okolicy ? Przepływ dużego prądu ? Pole magnetyczne ?

Cała historia jest ważna.

Z X-Raya to mógłbyś się jedynie dowiedzieć gdzie bond upalony. Może dać jakąś wskazówkę.

Widziałem już różne cuda.

Pozdrawiam

Adam Górski

O, tutaj bardzo dobry pomysł. Jak wygląda sprawa z dopasowaniem impedancji na szynach danych , adresowych ? Dopasowanie ścieżek jest ? Jeśli brak to pojawiają się przepięcia które stresują diody zabezpieczające i po czasie T umierają.

Tutaj pomocny byłby stackup i projekt PCB - gerbery wystarczą.

Pozdrawiam

Adam Górski

Linie danych i adresowe prowadzone sa tak aby miały w miarę jednakową długość. Przepięć nie widzę zbyt dużych, sygnał ucieka czasem 180-220mV poniżej poziomu masy jak patrzę na pinach najdalej umiejscowionej kostki flash... Za chwilę wyślę fotki. Czy takie poziomy przepięć już mogą być niebezpieczne?

Natomiast oglądając górną połówkę szyny danych zauważyłem spore kolizje na bitach D16..D31. Okazuje się, że procesor został błędnie skonfigurowany na 16-bitowy tryb dostępu do pamięci flash, tymczasem są tam dwie kostki, spięte równolegle do linii adresowych mające wspólne CE, OE i WE: jedna obsługuje dolną połówkę danych, druga górną.

Niezaprogramowany "górny" scalak z kimś się tam mocuje na liniach danych, próbując forsować swoje ffy, tylko z czym? 32-bitowa kostka SDRAM jest przecież nieaktywna gdy procek dostaje się do statycznego flash... Czyżby CPU spinał razem D0 z D16 D1 z D17 i tak dalej, obsługując tryb dostępu

32-bit do 16-bit pamięci? Ktoś wie może jak to działa?

Długość to jedno 50R to druga sprawa. Czyli szerokość ścieżki odległość od warstwy masy.

Fotki mają sens jeżeli masz około 1GHz pasma analogowego w oscyloskopie

• odpowiednią sondę.

To już zależy od producenta. Bywają niebezpieczne.

No to mogłoby być powodem.

Pozdrawiam

Adam Górski

Mam 350MHz pasma w oscylu i normalną sondę 10:1 500MHz w której zamiast pętli masy z krokodylkiem uzywam sprężynki nałożonej na końcówkę sondy i zbieram masę z pinu 52 kostki flash (do którego jest również podlutowany odsprzęgający 100nF) patrząc np. na pin 51 (D31).

Myślisz że CPU wystawia coś na D16..D31 w czasie odczytu z D0..D15??

Bo oprócz SDRAM, które w czasie dostępu do Flash ma wysoki DYCS0, więc powinno mieć linie danych w trybie wysokiej impedancji, jest tam tylko CPU...

Obiecane fotki z oscyla:

scalaki pamięci flash, po jednej fotce linia A0, D15 i z drugiego A0, D31.

W dniu 2018-06-18 o 19:55, Pszemol pisze:

Nie wnikam w te obrazki - nie mam doświadczenia, ale te przepięcia o których pisałem wynikające z impedancji połączeń struktury do pinów są nanosekundowe - można ich nie widzieć.

To trochę jak ESD - ludziom się wydawało, że czas narastania jest rzędu

1ns dopóki nie zrobili lepszego oscyloskopu - zawsze wychodzi, że czas narastania jest najkrótszy jaki może zmierzyć aktualnie posiadany sprzęt. P.G.

Ciekawe. Zapodaj może jeszcze słabe podciągnięcie do vcc lub gnd żeby zobaczyć czy to jest Hi-Z czy coś innego.

Adam

Użytkownik "Pszemol" napisał w wiadomości grup dyskusyjnych:pg8ok8$1ea$ snipped-for-privacy@dont-email.me...

Jakos watpie, aby tak. Zapewne po prostu czyta kolejne 16-bit slowo, tylko wewnetrznie przestawia sobie dane na starsze bity.

Ale czy adresy sie wtedy nie zmieniaja ? Moze jeszcze cos innego jest uruchamiane ... tylko czemu nie ma konfliktow takze na dolnej polowie ..

A moze to nie "mocowanie" tylko stan wysokiej impedancji ?

Nie mozesz wyciagnac tej kosci? To moze da sie jej CE lub OE odciac ?

J.

Spróbuję dziś wylutować górną kostkę flash, tą nieużywaną, i zobaczę co tam na tej szynie danych się dzieje... to musi być CPU, nie?

Spróbuję dziś wylutować górną kostkę flash, tą nieużywaną, i zobaczę co tam na tej szynie danych się dzieje... to musi być CPU, nie?