Użytkownik "Pszemol" napisał w wiadomości grup
dyskusyjnych:pgars6$m6b$...@d...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 ?

J.

do góry

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

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.

do góry

"J.F." <j...@p...onet.pl> wrote in message
news:5b28e0e9$0$685$65785112@news.neostrada.pl...
> Użytkownik "Pszemol" napisał w wiadomości grup
> dyskusyjnych:pg8ok8$1ea$...@d...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 ..

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.

do góry

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 ?

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

J.

do góry

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

do góry

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

J.

do góry

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

do góry

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

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

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

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

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

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

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

do góry

"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.
Nie rozumiem Twojego pytania.

do góry

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.

do góry