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

do góry

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

do góry

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.

do góry

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

do góry

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

do góry

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

do góry

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.

do góry

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.

do góry

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

do góry

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.

do góry