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

Nie, Wyraźnie widać CE i OE aktywne gdy D31 walczy... Nie rozumiem co robi procek wtedy myślac że górna połowa danych pusta.

Nie rozumiem też w jaki sposób układy się od tego niszczą permanentnie. To wciąż dla mnie trochę zagadka jest... Zwłaszcza że niektóre płyty mają np. uszkodzenie linii A10 w CPU.

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

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.

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 ?

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

J.

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.

Interesujące jest w tym momencie tylko zachowanie się górnych linii danych, bo zachowanie się dolnych wynika z normalnych cykli odczytów i zapisów 16-bitowych i tam się nie spodziewam kolizji. Prawdę mówiąc na górnej połowie szyny danych też się żadnych kolizji nie spodziewałem :-) Ale to już inna inszość...

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.

I nic wiecej ?

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.

Tym niemniej sie zobaczy, czy procesor steruje magistrala.

J.

W dniu 2018-06-20 o 14:17, Pszemol pisze:

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

Jeśli chodzi o zewnętrzną szynę adresową to nic więcej. Do proca jest oczywiście podłączone mnóstwo innych rzeczy. Jakoś te 208 pinów jest wykorzystane przecież :-)

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

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.

:-) Na razie to ja wariuje od ilosci zwrotów gwarancyjnych.

Odłącze CS0 od górnej kostki flash i zobaczę.

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

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

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.

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.

Adam

W dniu 2018-06-20 o 20:22, Pszemol pisze:

Ale sam pisałeś że jest w trybie 16b i czyta na jednej szynie dwa flasze.

My też nie, może daj kawałek schematu z oscylogramami.

Użytkownik "Janusz" napisał w wiadomości grup dyskusyjnych:pgfpiq$kht$ snipped-for-privacy@node1.news.atman.pl... W dniu 2018-06-20 o 20:22, Pszemol pisze:

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 ?

J.

Podłączam się pod OE i CS0 flasha i widzę że flash jest wybrany do odczytu gdy są te stany konfliktowe. SDRAMu nie oglądałem pod względem DYCS0 ale widzę krótsze cykle odczytu gdy CS0 flasha jest nieaktywny, i wtedy nie ma kolizji więc SDRAM jest odczytywana poprawnie.

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

To jest LPC4088 w obudowie 208 pinów... Poszukam jeszcze raz w datasheet ale nie pamiętam abym to widział.

Dokładnie tak. CPU omyłkowo czyta dwa razy 16bit z jednego chipa flash zamiast czytać oba na raz na pełnej szynie 32-bit.

Dokładnie tak.

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

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

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

J.

Na pewno w CPU, a nie DRAM lub flash ?

Tez jestem ciekaw.

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.

J.

No na pewno :) Sam podnosiłem nóżkę procesora...

To akurat jest znane - pierwsza wersja tej płytki miała nieobsadzony "górny" flash i software pracował z jednym flash, 16-bit mode. Potem zrobilismy płytki z dwoma kostkami flash i software został niezmieniony ale nie spodziewalem sie żadnych problemów, oczekując od procesora zgodną współpracę :) przeliczyłem się :)

Algorytm programowania wymaga przełączenie kostki z trybu odczyt w tryb programowania więc górna kostka nic nie wie na ten temat gdy nie widzi takich sekwencji adresów i danych. Do programowania tych kostek w trybie 32bity napisałem specjalną wersję programu który się nie uruchomił w trybie 16-bit. Efekt jest taki ze dolna kostka zaprogramowana poprawnie a górna pusta.

Mnie też.

Sprawdzałem na płycie która nie miała żadnych objawów niedziałania.