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

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

Niby nie ma, ale procek z natury moze chciec wystawic dwa impulsy RD.
tu RD nie ma, to moze inne ..

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.

dasz rade podlaczyc sie pod te CS i inne linie ?
Ja bym obejrzal oscyloskopem/analiatorem czy jednak DRAM nie jest
aktywna w czasie czytania flasha.

Albo po prostu skonfiguruj dobrze i moze problem zniknie :-)

J.

"Piotr Gałka" <piotr.galka@cutthismicromade.pl> wrote in message
news:pgdqr4$clv$1$PiotrGalka@news.chmurka.net...
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).

Jedna kość obsługuje przecież D0..D15, druga obsługuje D16..D31.
Ale sam pisałeś że jest w trybie 16b i czyta na jednej szynie dwa flasze.

Nie rozumiem Twojego pytania.
My też nie, może daj kawałek schematu z oscylogramami.

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

Jedna kość obsługuje przecież D0..D15, druga obsługuje D16..D31.
Ale sam pisałeś że jest w trybie 16b i czyta na jednej szynie dwa
flasze.

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

Niby nie ma, ale procek z natury moze chciec wystawic dwa impulsy RD.
tu RD nie ma, to moze inne ..

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.

dasz rade podlaczyc sie pod te CS i inne linie ?
Ja bym obejrzal oscyloskopem/analiatorem czy jednak DRAM
nie jest aktywna w czasie czytania flasha.

Albo po prostu skonfiguruj dobrze i moze problem zniknie

A ja bym się chętnie dowiedział co to za procek i spojrzał w dokumentacje
co powinno być.

Zwykle jest tam tez napisane czego się spodziewać w 16 bitowych
trybach dostępu.

Użytkownik "Janusz" napisał w wiadomości grup
dyskusyjnych:pgfpiq$kht$1@node1.news.atman.pl...
W dniu 2018-06-20 o 20:22, Pszemol pisze:
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).

Jedna kość obsługuje przecież D0..D15, druga obsługuje D16..D31.
Ale sam pisałeś że jest w trybie 16b i czyta na jednej szynie dwa flasze.

Nie, flashe sa rownolegle i daja 32 bit.

Tyle ze procek skonfigurowany (omylkowo) na 16-bit, wiec slowo czyta na
dwa razy.

Oczywiscie w obu cyklach "gorny flash" tez podaje dane, ktore procek
powinien ignorowac, ale widac jest tam jeszcze jakis konflikt na
magistrali danych.
Jak rozumiem - na pewno nie z dolnym flashem, bo ten na innych bitach D
polaczony.

Swoja droga - ze to w ogole działa ?
Puste te flashe ?
Przypadkiem dobrze sie programuja mimo omylki ?

Swoja droga - ze to w ogole działa ?
Puste te flashe ?
Przypadkiem dobrze sie programuja mimo omylki ?

Ten górny jest pusty, bo w czasie programowania CPU też "myśli" że
ma jedną kostkę 16 bit, więc nic nie wystawia do zapisu na D16..D31.

A więc górny flash podczas odczytu forsuje FFy ale CPU pewnie
chce ustawiać 00 bo mam jakieś 1.5V tak na oko

Albo po prostu skonfiguruj dobrze i moze problem zniknie :-)

Owszem, po skonfigurowaniu cpu aby odczytywał flash
w trybie 32-bitowym problem kolizji znika. D31 zaczyna
wyglądać wtedy normalnie.

Ja mam jednak problem taki, że płytki wracają uszkodzone na
gwarancji a ja nie jestem do końca przekonany że to te kolizje
powodują uszkodzenia. Bo sekcje zwłok na płytkach które miały
scalaki w miarę sprawne (czyli nie parzyły i nie zwierały 3.3V)
zwracały rezultat typu zwarta linia A10 w CPU lub stały poziom

2V na wyjściu jednego pinu SDRAM - innymi słowy nie rozumiem
jak walczący flash z cpu na szynach danych może procesorowi
uszkodzić linię adresową A10 albo uszkodzić SDRAM które jest
niewybrane DYCS0 w czasie tychże kolizji.

Innymi słowy znalazłem coś, ale nie wiem czy jak naprawię to
coś przełączając flash na poprawne 32-bity to czy problemy znikną.

Użytkownik "Pszemol" napisał w wiadomości grup
dyskusyjnych:pgg3s7$du7$1@dont-email.me...
"J.F." <jfox_xnospamx@poczta.onet.pl> wrote in message
Albo po prostu skonfiguruj dobrze i moze problem zniknie :-)

Owszem, po skonfigurowaniu cpu aby odczytywał flash
w trybie 32-bitowym problem kolizji znika. D31 zaczyna
wyglądać wtedy normalnie.

Ja mam jednak problem taki, że płytki wracają uszkodzone na
gwarancji a ja nie jestem do końca przekonany że to te kolizje
powodują uszkodzenia. Bo sekcje zwłok na płytkach które miały
scalaki w miarę sprawne (czyli nie parzyły i nie zwierały 3.3V)
zwracały rezultat typu zwarta linia A10 w CPU lub stały poziom

Na pewno w CPU, a nie DRAM lub flash ?

2V na wyjściu jednego pinu SDRAM - innymi słowy nie rozumiem
jak walczący flash z cpu na szynach danych może procesorowi
uszkodzić linię adresową A10 albo uszkodzić SDRAM które jest
niewybrane DYCS0 w czasie tychże kolizji.

Tez jestem ciekaw.

Innymi słowy znalazłem coś, ale nie wiem czy jak naprawię to
coś przełączając flash na poprawne 32-bity to czy problemy znikną.

Tez podejrzewam ze nie. Czas powtorzyc badania EMC/ESD ?

Ale ... jesli jest konflikt, cos tam sie grzeje, moze i rozne rzeczy
moga sie w srodku przegrzac.
A potem usterka sie moze propagowac - tzn np zwarcie na linii danych w
jednej kosci, podgrzeje cos w drugiej kosci i usmazy okolice na
krzemie
... choc bylbym chyba ostatnim, ktory by podejrzewal stałe usterki od
takiego konfliktu.

No i skad w ogole ten konflikt ...

Moze warto przy okazji sprawdzic ustawienia interfejsu SDRAM.

Użytkownik "Pszemol" napisał w wiadomości grup
dyskusyjnych:pgg43m$fl7$1@dont-email.me...
"J.F." <jfox_xnospamx@poczta.onet.pl> wrote in message
Swoja droga - ze to w ogole działa ?
Puste te flashe ?
Przypadkiem dobrze sie programuja mimo omylki ?

Ten górny jest pusty, bo w czasie programowania CPU też "myśli" że
ma jedną kostkę 16 bit, więc nic nie wystawia do zapisu na D16..D31.

Ale ten algorytm programowania nie jest jakis bardziej skomplikowany ?
I czy w efekcie nie bedzie zepsuty w takim ukladzie ?

A więc górny flash podczas odczytu forsuje FFy ale CPU pewnie
chce ustawiać 00 bo mam jakieś 1.5V tak na oko :-)

Troche by mnie zdziwilo, gdyby w czasie odczytu dolnych bitow, uP
ustawial górne na 0.

A propos - sprawdzales to na nowej plycie ?
Moze kostka jakos walnieta ? np nie potrafi 3.3V dac ?
I niekoniecznie flash - moze wlasnie RAM ...

"Piotr Gałka" <piotr.galka@cutthismicromade.pl> wrote in message
news:pgdqr4$clv$1$PiotrGalka@news.chmurka.net...
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).

Jedna kość obsługuje przecież D0..D15, druga obsługuje D16..D31.
Nie rozumiem Twojego pytania.

W dniu 2018-06-20 o 20:22, Pszemol pisze:
Jedna kość obsługuje przecież D0..D15, druga obsługuje D16..D31.
Nie rozumiem Twojego pytania.

Napisałeś:
"inkrementuje adres i odczytuje górną połówkę danych na liniach D0..D15".

Założyłem, że przed inkrementowaniem czyta D0..D15. Skoro po
inkrementowaniu też to .....

Dnia Thu, 21 Jun 2018 20:43:44 +0200, Piotr Gałka napisał(a):
W dniu 2018-06-20 o 20:22, Pszemol pisze:
Jedna kość obsługuje przecież D0..D15, druga obsługuje D16..D31.
Nie rozumiem Twojego pytania.

Napisałeś:
"inkrementuje adres i odczytuje górną połówkę danych na liniach D0..D15".

Założyłem, że przed inkrementowaniem czyta D0..D15. Skoro po
inkrementowaniu też to .....

Procesor ustawiony omylkowo na 16-bit flash, to czyta dwa razy z
D0..15.

A dwie pamieci uczciwe - 32 bity naraz dostarczaja.

W dniu 2018-06-20 o 20:22, Pszemol pisze:
"Piotr Gałka" <piotr.galka@cutthismicromade.pl> wrote in message
news:pgdqr4$clv$1$PiotrGalka@news.chmurka.net...
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).

Jedna kość obsługuje przecież D0..D15, druga obsługuje D16..D31.
Ale sam pisałeś że jest w trybie 16b i czyta na jednej szynie dwa flasze.

Nie rozumiem Twojego pytania.
My też nie, może daj kawałek schematu z oscylogramami.

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

Niby nie ma, ale procek z natury moze chciec wystawic dwa impulsy RD.
tu RD nie ma, to moze inne ..