Jak znaleźć przyczyny przegrzewania procesora NXP Cortex M4 i SDRAM?

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

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

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?

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.

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.

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?

Użytkownik "Pszemol" napisał w wiadomości grup
dyskusyjnych:pgars6$m6b$2@dont-email.me...
"Adam Górski" <gorskiamalpawpkropkapeel_@xx> wrote in message
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?

Malo prawdopodobne. Procek przeciez wie, ze czyta, a nie pisze.

Moze on tam zapisuje, a WE/OE zle dekodowane ?

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

Użytkownik "Pszemol" napisał w wiadomości grup
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...
[...]
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 ..

Dlaczego miałyby być konflikty na dolnej połowie? Wytłumacz...

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

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

Mogę wyciągnąć tą kość, tylko wtedy spodziewam się, że problem
zostanie usunięty i nie będę obserwował niczego nadzwyczajnego.
W czasie obserwowanych kolizji wystawiany jest CE i OE do kosci
flash.

Użytkownik "Pszemol" napisał w wiadomości grup
dyskusyjnych:pgdf3m$eiq$1@dont-email.me...
"J.F." <jfox_xnospamx@poczta.onet.pl> wrote in message
Użytkownik "Pszemol" napisał w wiadomości grup
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...
[...]
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 ..

Dlaczego miałyby być konflikty na dolnej połowie? Wytłumacz...

Jesli flash i cos innego sa jednoczenie aktywowane ... to to cos innego
zapewne nie ma tylko bitow 16..31, tylko 0..31, to i na "dolnym flash"
powinien byc konflikt.

Swoja droga - kosci 32 bit to chyba nie masz duzo - moze jedna z RAM
koliduje ?

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

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

Mogę wyciągnąć tą kość, tylko wtedy spodziewam się, że problem
zostanie usunięty i nie będę obserwował niczego nadzwyczajnego.
W czasie obserwowanych kolizji wystawiany jest CE i OE do kosci flash.

I trzeba bedzie zobaczyc co jeszcze odzywa sie wtedy na magistrali.

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

Dlaczego miałyby być konflikty na dolnej połowie? Wytłumacz...

Jesli flash i cos innego sa jednoczenie aktywowane ... to to cos
innego zapewne nie ma tylko bitow 16..31, tylko 0..31, to i na
"dolnym flash" powinien byc konflikt.

Swoja droga - kosci 32 bit to chyba nie masz duzo - moze jedna z
RAM koliduje ?

Pisałem wcześniej chyba co jest tam do procka podłączone:
1 sztuka 32-bitowa SDRAM (synchronous-dynamic RAM).
2 sztuki 16-bitowe FLASH (wspólny CE, OE, WE i address bus).

Procek jest błędnie ustawiony aby myślał, że ma tylko jedną
kostkę flash, i odczyt 32-bitowego słowa robi na dwa takty:
najpierw wystawia "dolny" adres, OE, CE i odczytuje dolną
połówkę danych, potem, niezmieniając stanu OE i CE inkrementuje
adres i odczytuje górną połówkę danych na liniach D0..D15.

Mogę wyciągnąć tą kość, tylko wtedy spodziewam się, że problem
zostanie usunięty i nie będę obserwował niczego nadzwyczajnego.
W czasie obserwowanych kolizji wystawiany jest CE i OE do kosci
flash.

I trzeba bedzie zobaczyc co jeszcze odzywa sie wtedy na magistrali.

No ale na mojej płycie oprócz procesora 208-pinów LPC4088 (Cortex M4)
i pamięci SDRAM i tych dwu kostek FLASH nie ma tam niczego innego.

Procek jest błędnie ustawiony aby myślał, że ma tylko jedną
kostkę flash, i odczyt 32-bitowego słowa robi na dwa takty:
najpierw wystawia "dolny" adres, OE, CE i odczytuje dolną
połówkę danych, potem, niezmieniając stanu OE i CE inkrementuje
adres i odczytuje górną połówkę danych na liniach D0..D15.

Użytkownik "Pszemol" napisał w wiadomości grup
dyskusyjnych:pgdgla$oip$1@dont-email.me...
"J.F." <jfox_xnospamx@poczta.onet.pl> wrote in message
Ale czy adresy sie wtedy nie zmieniaja ? Moze jeszcze cos innego jest
uruchamiane ... tylko czemu nie ma konfliktow takze na dolnej polowie
..

Dlaczego miałyby być konflikty na dolnej połowie? Wytłumacz...

Jesli flash i cos innego sa jednoczenie aktywowane ... to to cos innego
zapewne nie ma tylko bitow 16..31, tylko 0..31, to i na "dolnym flash"
powinien byc konflikt.

Swoja droga - kosci 32 bit to chyba nie masz duzo - moze jedna z RAM
koliduje ?

Pisałem wcześniej chyba co jest tam do procka podłączone:
1 sztuka 32-bitowa SDRAM (synchronous-dynamic RAM).
2 sztuki 16-bitowe FLASH (wspólny CE, OE, WE i address bus).

I nic wiecej ?

Procek jest błędnie ustawiony aby myślał, że ma tylko jedną
kostkę flash, i odczyt 32-bitowego słowa robi na dwa takty:
najpierw wystawia "dolny" adres, OE, CE i odczytuje dolną
połówkę danych, potem, niezmieniając stanu OE i CE inkrementuje
adres i odczytuje górną połówkę danych na liniach D0..D15.

Jestes pewien, ze bez zmiany CE, OE ? Nie ma dwoch impulsow

Dekoder adresow masz zewnetrzny, czy korzystasz z wbudowanego ?
Bo zdziwilbym sie, gdyby procesor wystawial cos na D16-31 w czasie
czytania na liniach 0-15.

Natomiast przez to ustawienie adresy na zewnetrznej magistrali sie
zmienily - to i zewnetrzny dekoder mogl zwariowac.

Mogę wyciągnąć tą kość, tylko wtedy spodziewam się, że problem
zostanie usunięty i nie będę obserwował niczego nadzwyczajnego.
W czasie obserwowanych kolizji wystawiany jest CE i OE do kosci flash.

I trzeba bedzie zobaczyc co jeszcze odzywa sie wtedy na magistrali.

No ale na mojej płycie oprócz procesora 208-pinów LPC4088 (Cortex M4)
i pamięci SDRAM i tych dwu kostek FLASH nie ma tam niczego innego.

Tym niemniej sie zobaczy, czy procesor steruje magistrala.

W dniu 2018-06-20 o 14:17, Pszemol pisze:
Procek jest błędnie ustawiony aby myślał, że ma tylko jedną
kostkę flash, i odczyt 32-bitowego słowa robi na dwa takty:
najpierw wystawia "dolny" adres, OE, CE i odczytuje dolną
połówkę danych, potem, niezmieniając stanu OE i CE inkrementuje
adres i odczytuje górną połówkę danych na liniach D0..D15.

Wytłumacz jak to jest zrobione.
Skoro OE i CE się nie zmieniają a zmienia się adres o 1 to A0 powinno
robić za CE do jednej kości i zanegowane A0 za CE do drugiej.

Ale piszesz, że CE się nie zmienia.

Czy w czasie tego inkrementowania nie ma chwili, kiedy obie kości walczą
ze sobą na liniach danych (na przykład w czasie równym czasowi propagacji
negatora na linii A0).

Procek jest błędnie ustawiony aby myślał, że ma tylko jedną
kostkę flash, i odczyt 32-bitowego słowa robi na dwa takty:
najpierw wystawia "dolny" adres, OE, CE i odczytuje dolną
połówkę danych, potem, niezmieniając stanu OE i CE inkrementuje
adres i odczytuje górną połówkę danych na liniach D0..D15.

Jestes pewien, ze bez zmiany CE, OE ? Nie ma dwoch impulsow

Nie ma potrzeby dwu impulsów przy czytaniu pamięci flash.

Dekoder adresow masz zewnetrzny, czy korzystasz z wbudowanego ?
Bo zdziwilbym sie, gdyby procesor wystawial cos na D16-31 w czasie
czytania na liniach 0-15.

Nie mam zewnętrznego dekodera adresów - konfiguruję
procesor pod względem takich rzeczy jak rozmiar stron
pamięci SDRAM i rozmiaru bloków pamięci flash.
Kostki pamięci są podłączone bezpośrednio do linii adresowych
procesora - mają swoje własne CS0 i DYCS0.