>> Gdybyś tak zrobił jedno miejsce przez które przechodzą wszystkie zapisy
>> i odczyty z printfem jakie zapisy idą do pamięci, to by pewnie było już
>> po problemie.
>
> Hmmm... Nie bardzo rozumiem ten pomysł...
> Może zasugerowałbyś jakiś przykład?
> W czasie programowania piszę przecież do pamięci bezpośrednio odwołując się
> do wskaźników... Przy odczycie, w czasie kasowania i zapisu pamięć
> przestawia jeden bit (toggle) co wskazuje na operację w toku...
>

Tak ale można to zrobić poprzez np. makro lub funkcje i przekierować to
co wychodzi do flasha i jednocześnie do printfa lub do bufora w ramie
tak żeby mieć rejestr z tego co wyszło i przyszło. Jedym słowem
logowanie. Tak żeby mieć pewność że sekwencja zapisu zgadza się z teorią.



>> Do sprawdzenia:
>> 1. Reprezentacja danych w pamięci. Czy aby na pewno bajty/słowa nie są
>> zamienione.
>
> Domyślam się że nie są zamienione, bo gdyby były to nie udawałoby się
> czasem skasować i zapisać, a czasem się udaje...

A nie trzeba tam gdzies czekać na bity ze status registru ?

>
>> 2. Czy w Twoim przypadku rozmiar sektora jest 0x20000 ? A może 0x40000 ?
>> Masz przesunięty adres.
>
> Używam kostek M29W640GL.
> To są pamięci 64Mb z 128 sektorów po 64KB/16KW każdy. Gdybym adresował
> 8-bitowo to sektor byłby od 0x0000 do 0xffff.
> Ale tu mi trochę zadałeś klina, bo z jednej strony każda kostka pamięci ma
> widzieć swój adres, ze swojego lokalnego punktu widzenia a z drugiej strony
> mam procesor, który myśli że ma pamięć 32-bitową i interpretuje moje
> wskazniki zgodnie ze swoim rozumieniem adresowania 32-bitowego z
> przesuniętym A2 na pin A0. Muszę to jeszcze raz przetrawić...

Tak mi się wydaje.

>> 3. Jak nie jesteś pewny to oscyloskop do łapy i sprawdź czy jest to co
>> Ci się wydaje.
> Dobre :-)

Czemu dobre ? Życie. No nie mów że dostęp do flasha jest jakiś
ekstremalnie szybki lub że nie da się tego zobaczyć. Że o debuggerach
nie wspomnę.

Adam Górski