On 2018-06-08 12:47, Piotr Gałka wrote:
> W dniu 2018-06-08 o 04:14, Pszemol pisze:
>> Procesor embedded NXP serii Cortex M4... Pracuje zaledwie 100MHz...
>> W czasie normalnej pracy jest zimny, temperatura pokojowa...
>>
>> Klient zwraca już 3 płytę w której procesor zwiera szynę 3V3
>> i grzeje się tak, że dotykając go palcem ciężko wytrzymać...
>>
>> Do procesora podłączone kostki zewnętrznej pamięci flash i SDRAM.
>> Też normalnie zimne.
>>
>> Na próbę biorę jedną płytkę: wymieniam starannie ten grzejący się
>> cpu... mierzę napięcia, wszystko ok. Procesor programuję, program
>> startuje, na LCD obraz, za moment grzeje się niebotycznie kostka
>> SDRAM obok CPU...
>>
>> Płytka pracowała miesiąc bez zarzutu i nagle taki zwrot.
>>
>> Projekt testowany na odporność na ESD bardzo dokładnie,
>> zamknięty w metalowej obudowie, jedyne "wejście" to przez
>> LCD ale jest też zabezpieczony i od tej strony niczego
>> się nie spodziewam.
>>
>> Czy można jakoś "pośmiertnie" dojść przyczyny uszkodzenia
>> kostki pamięci lub cpu? Nie wiem, mierząc omomierzem
>> piny do masy czy coś takiego? Albo prześwietlając Xrayem ? :-)
>>
>> Podpowiedźcie - co można sprawdzić?
>
> 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.

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

do góry

Adam Górski <gorskiamalpawpkropkapeel_@xx> wrote:
> On 2018-06-08 12:47, Piotr Gałka wrote:
>> W dniu 2018-06-08 o 04:14, Pszemol pisze:
>>> Procesor embedded NXP serii Cortex M4... Pracuje zaledwie 100MHz...
>>> W czasie normalnej pracy jest zimny, temperatura pokojowa...
>>>
>>> Klient zwraca już 3 płytę w której procesor zwiera szynę 3V3
>>> i grzeje się tak, że dotykając go palcem ciężko wytrzymać...
>>>
>>> Do procesora podłączone kostki zewnętrznej pamięci flash i SDRAM.
>>> Też normalnie zimne.
>>>
>>> Na próbę biorę jedną płytkę: wymieniam starannie ten grzejący się
>>> cpu... mierzę napięcia, wszystko ok. Procesor programuję, program
>>> startuje, na LCD obraz, za moment grzeje się niebotycznie kostka
>>> SDRAM obok CPU...
>>>
>>> Płytka pracowała miesiąc bez zarzutu i nagle taki zwrot.
>>>
>>> Projekt testowany na odporność na ESD bardzo dokładnie,
>>> zamknięty w metalowej obudowie, jedyne "wejście" to przez
>>> LCD ale jest też zabezpieczony i od tej strony niczego
>>> się nie spodziewam.
>>>
>>> Czy można jakoś "pośmiertnie" dojść przyczyny uszkodzenia
>>> kostki pamięci lub cpu? Nie wiem, mierząc omomierzem
>>> piny do masy czy coś takiego? Albo prześwietlając Xrayem ? :-)
>>>
>>> Podpowiedźcie - co można sprawdzić?
>>
>> 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.
>
> 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ą.

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?

do góry

>>>> Procesor embedded NXP serii Cortex M4... Pracuje zaledwie 100MHz...
>>>> W czasie normalnej pracy jest zimny, temperatura pokojowa...
>>>>
>>>> Klient zwraca już 3 płytę w której procesor zwiera szynę 3V3
>>>> i grzeje się tak, że dotykając go palcem ciężko wytrzymać...
>>>>
>>>> Do procesora podłączone kostki zewnętrznej pamięci flash i SDRAM.
>>>> Też normalnie zimne.
>>>>
>>>> Na próbę biorę jedną płytkę: wymieniam starannie ten grzejący się
>>>> cpu... mierzę napięcia, wszystko ok. Procesor programuję, program
>>>> startuje, na LCD obraz, za moment grzeje się niebotycznie kostka
>>>> SDRAM obok CPU...
>>>>
>>>> Płytka pracowała miesiąc bez zarzutu i nagle taki zwrot.
>>>>
>>>> Projekt testowany na odporność na ESD bardzo dokładnie,
>>>> zamknięty w metalowej obudowie, jedyne "wejście" to przez
>>>> LCD ale jest też zabezpieczony i od tej strony niczego
>>>> się nie spodziewam.
>>>>
>>>> Czy można jakoś "pośmiertnie" dojść przyczyny uszkodzenia
>>>> kostki pamięci lub cpu? Nie wiem, mierząc omomierzem
>>>> piny do masy czy coś takiego? Albo prześwietlając Xrayem ? :-)
>>>>
>>>> Podpowiedźcie - co można sprawdzić?
>>>
>>> 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.
>>
>> 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ą.

> Linie danych i adresowe prowadzone sa tak aby miały w miarę jednakową
> długość.

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

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

Fotki mają sens jeżeli masz około 1GHz pasma analogowego w oscyloskopie
+ odpowiednią sondę.

> Czy takie poziomy przepięć już mogą być niebezpieczne?

To już zależy od producenta. Bywają 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ą.

No to mogłoby być powodem.


Pozdrawiam

Adam Górski

do góry

"Adam Górski" <gorskiamalpawpkropkapeel_@xx> wrote in message
news:5b27e870$0$601$65785112@news.neostrada.pl...
>>> Tutaj pomocny byłby stackup i projekt PCB - gerbery wystarczą.
>
>> Linie danych i adresowe prowadzone sa tak aby miały w miarę jednakową
>> długość.
>
> Długość to jedno 50R to druga sprawa. Czyli szerokość ścieżki odległość od
> warstwy masy.
>
>> 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.
>
> Fotki mają sens jeżeli masz około 1GHz pasma analogowego w oscyloskopie +
> odpowiednią sondę.

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

>> Czy takie poziomy przepięć już mogą być niebezpieczne?
>
> To już zależy od producenta. Bywają 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ą.
>
> No to mogłoby być powodem.

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

do góry

"Adam Górski" <gorskiamalpawpkropkapeel_@xx> wrote in message
news:5b27e870$0$601$65785112@news.neostrada.pl...
>> 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.
>
> Fotki mają sens jeżeli masz około 1GHz pasma analogowego w oscyloskopie +
> odpowiednią sondę.

Obiecane fotki z oscyla: https://photos.app.goo.gl/3THmA2F17Nvo1wLK9
Dwa scalaki pamięci flash, po jednej fotce linia A0, D15 i z drugiego A0,
D31.

do góry

W dniu 2018-06-18 o 19:55, Pszemol pisze:
> "Adam Górski" <gorskiamalpawpkropkapeel_@xx> wrote in message
> news:5b27e870$0$601$65785112@news.neostrada.pl...
>>> 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.
>>
>> Fotki mają sens jeżeli masz około 1GHz pasma analogowego w
>> oscyloskopie + odpowiednią sondę.
>
> Obiecane fotki z oscyla: https://photos.app.goo.gl/3THmA2F17Nvo1wLK9
> Dwa scalaki pamięci flash, po jednej fotce linia A0, D15 i z drugiego
> A0, D31.

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.

do góry

>>>> Tutaj pomocny byłby stackup i projekt PCB - gerbery wystarczą.
>>
>>> Linie danych i adresowe prowadzone sa tak aby miały w miarę jednakową
>>> długość.
>>
>> Długość to jedno 50R to druga sprawa. Czyli szerokość ścieżki
>> odległość od warstwy masy.
>>
>>> 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.
>>
>> Fotki mają sens jeżeli masz około 1GHz pasma analogowego w
>> oscyloskopie + odpowiednią sondę.
>
> 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).
>
>>> Czy takie poziomy przepięć już mogą być niebezpieczne?
>>
>> To już zależy od producenta. Bywają 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ą.
>>
>> No to mogłoby być powodem.
>
> 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...

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

do góry

Użytkownik "Pszemol" napisał w wiadomości grup
dyskusyjnych:pg8ok8$1ea$...@d...me...
>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?

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.

do góry

"Adam Górski" <gorskiamalpawpkropkapeel_@xx> wrote in message
news:5b28bbc8$0$603$65785112@news.neostrada.pl...
>>>> 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ą.
>>>
>>> No to mogłoby być powodem.
>>
>> 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...
>
> Ciekawe. Zapodaj może jeszcze słabe podciągnięcie do vcc lub gnd żeby
> zobaczyć czy to jest Hi-Z czy coś innego.

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?

do góry

"Adam Górski" <gorskiamalpawpkropkapeel_@xx> wrote in message
news:5b28bbc8$0$603$65785112@news.neostrada.pl...
>>>> 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ą.
>>>
>>> No to mogłoby być powodem.
>>
>> 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...
>
> Ciekawe. Zapodaj może jeszcze słabe podciągnięcie do vcc lub gnd żeby
> zobaczyć czy to jest Hi-Z czy coś innego.

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?

do góry