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