eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.misc.elektronikaTypowe przyczyny nadmiernego grzania się układów pamięci i cpu?
Ilość wypowiedzi w tym wątku: 51

  • 31. Data: 2018-06-21 10:25:53
    Temat: Re: Typowe przyczyny nadmiernego grzania się układów pamięci i cpu?
    Od: Adam Górski <gorskiamalpawpkropkapeel_@xx>

    On 2018-06-21 10:06, J.F. wrote:
    > Użytkownik "Pszemol"  napisał w wiadomości grup
    > dyskusyjnych:pge5uv$85h$...@d...me...
    > "J.F." <j...@p...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.
    >

    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


  • 32. Data: 2018-06-21 11:02:14
    Temat: Re: Typowe przyczyny nadmiernego grzania się układów pamięci i cpu?
    Od: Janusz <j...@o...pl>

    W dniu 2018-06-20 o 20:22, Pszemol pisze:
    > "Piotr Gałka" <p...@c...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.

    --
    Pozdr
    Janusz


  • 33. Data: 2018-06-21 13:00:59
    Temat: Re: Typowe przyczyny nadmiernego grzania się układów pamięci i cpu?
    Od: "J.F." <j...@p...onet.pl>

    Użytkownik "Janusz" napisał w wiadomości grup
    dyskusyjnych:pgfpiq$kht$...@n...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 ?

    J.


  • 34. Data: 2018-06-21 13:58:10
    Temat: Re: Typowe przyczyny nadmiernego grzania się układów pamięci i cpu?
    Od: "Pszemol" <P...@P...com>

    "J.F." <j...@p...onet.pl> wrote in message
    news:5b2b5c6e$0$594$65785112@news.neostrada.pl...
    > Użytkownik "Pszemol" napisał w wiadomości grup
    > dyskusyjnych:pge5uv$85h$...@d...me...
    > "J.F." <j...@p...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.

    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.

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


  • 35. Data: 2018-06-21 13:59:10
    Temat: Re: Typowe przyczyny nadmiernego grzania się układów pamięci i cpu?
    Od: "Pszemol" <P...@P...com>

    "Adam Górski" <gorskiamalpawpkropkapeel_@xx> wrote in message
    news:5b2b6113$0$671$65785112@news.neostrada.pl...
    > 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.

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


  • 36. Data: 2018-06-21 14:02:10
    Temat: Re: Typowe przyczyny nadmiernego grzania się układów pamięci i cpu?
    Od: "Pszemol" <P...@P...com>

    "J.F." <j...@p...onet.pl> wrote in message
    news:5b2b856d$0$614$65785112@news.neostrada.pl...
    > Użytkownik "Janusz" napisał w wiadomości grup
    > dyskusyjnych:pgfpiq$kht$...@n...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.

    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.

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

    Dokładnie tak.

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


  • 37. Data: 2018-06-21 14:48:00
    Temat: Re: Typowe przyczyny nadmiernego grzania się układów pamięci i cpu?
    Od: "J.F." <j...@p...onet.pl>

    Użytkownik "Pszemol" napisał w wiadomości grup
    dyskusyjnych:pgg43m$fl7$...@d...me...
    "J.F." <j...@p...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 ...

    J.









  • 38. Data: 2018-06-21 16:36:03
    Temat: Re: Typowe przyczyny nadmiernego grzania się układów pamięci i cpu?
    Od: "J.F." <j...@p...onet.pl>

    Użytkownik "Pszemol" napisał w wiadomości grup
    dyskusyjnych:pgg3s7$du7$...@d...me...
    "J.F." <j...@p...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.

    J.


  • 39. Data: 2018-06-21 18:38:33
    Temat: Re: Typowe przyczyny nadmiernego grzania się układów pamięci i c pu?
    Od: Pszemol <P...@P...com>

    J.F. <j...@p...onet.pl> wrote:
    > Użytkownik "Pszemol" napisał w wiadomości grup
    > dyskusyjnych:pgg3s7$du7$...@d...me...
    > "J.F." <j...@p...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 ?

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

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

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



  • 40. Data: 2018-06-21 18:38:35
    Temat: Re: Typowe przyczyny nadmiernego grzania się układów pamięci i c pu?
    Od: Pszemol <P...@P...com>

    J.F. <j...@p...onet.pl> wrote:
    > Użytkownik "Pszemol" napisał w wiadomości grup
    > dyskusyjnych:pgg43m$fl7$...@d...me...
    > "J.F." <j...@p...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 ?

    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.

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

    Mnie też.

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

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


strony : 1 ... 3 . [ 4 ] . 5 . 6


Szukaj w grupach

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: