eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.misc.elektronikaTypowe przyczyny nadmiernego grzania się układów pamięci i cpu? › Re: Typowe przyczyny nadmiernego grzania się układów pamięci i cpu?
  • Data: 2018-06-20 14:17:57
    Temat: Re: Typowe przyczyny nadmiernego grzania się układów pamięci i cpu?
    Od: "Pszemol" <P...@P...com> szukaj wiadomości tego autora
    [ pokaż wszystkie nagłówki ]

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

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

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

    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.

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

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: