Re: Pamięć SRAM nie działa z Z80182

Sep 03, 2025 Last reply: 10 months ago 5 Replies

Ok, udało mi się ustalić jedną rzecz. Wygląda na to, że wystąpienia problemu z zapisem/odczytem do/z RAM-u jest uzależnione od typu użytego w projekcie flasha. Gdy korzystałem z ST29F040 nie działało wcale, natomiast w przypadku pamięci Hyundai HY29F040 część operacji zapis/odczyt się udaje. Powiedziałbym, że jakieś



50%. Oczywiście w takiej sytuacji nadal nie mogę korzystać ze stosu. Jest to o tyle dziwne, że wcześniej próbowałem już obniżenia zegara systemowego (z 12,5 MHz do 4 MHz) i dodawania wait-state'ów dla operacji na flashu i RAM-ie.

Zresztą, nawet przy zegarze 12,4 MHz relatywnie współczesne pamięci powinny zwalniać magistralę na czas, przed kolejną transmisją. Tymczasem wygląda na to, że mam do czynienia z jakimś konfliktem na magistrali...


A dekoder adresów masz prawidłowy? Może flash wysyła dane razem z RAM i wygrywa silniejszy?

J.

To normalnie byłoby moim głównym założeniem, ale nie tym razem. Dekoder adresów pamięci jest jednym z peryferiów Z80182. Układ ma dwa piny: /ROMCS i /RAMCS. Za pomocą zestawu trzech rejestrów można ustawiać zakresy adresów: górna granica ROM, dolne granica RAM i górna granica RAM. Jest też bit konfiguracyjny, który pozwala zupełnie wyłączyć obsługę ROM-u. Obowiązuje zasada, że ROM (o ile jest aktywny) ma priorytet nad RAM-em, nie ma więc możliwości, żeby obydwie linie CS były aktywne jednocześnie. Domyślnie, po resecie ROM zajmuje całą przestrzeń adresową. Ja zmodyfikowałem konfigurację w ten sposób, że od 0x0000 do 0x7FFF mamy ROM, a od 0x8000-0xFFFF RAM. I faktycznie po takim ustawieniu adresów pojawia się aktywność na linii /RAMCS, gdy próbuję operować na adresie powyżej 0x8000.

Bardziej zastanawiam się czy przypadkiem którejś pamięci (raczej flashowi) uwolnienie magistrali nie zajmuje za dużo czasu po deaktywacji linii CS i koleje urządzenie trafia na ciągle aktywne linie danych. Z drugiej strony to tylko 12,5 MHz...

Takie sprytne. Ale tak na oko: /CE pamięci trzeba podłączyć do (/RAMCS or /MERQ), no chyba, że RAMCS już zawiera ten /MERQ,

/OE pamięci podłączamy do /RD /WE pamięci podłączamy do /WR

A nawet 4MHz jak pisałeś.

J.

Tak. Sygnały RAMCS i ROMCS są generowane z uwzględnieniem MREQ. Dostępne są też sygnały MRD i MWR, (RD/WR z MREQ) ale z nich nie korzystam, bo dostępne są na multipleksowanych pinach, których potrzebuję do alternatywnych funkcji. Na magistrali systemowej mam standardowe RD/WR.

Tak, dokładnie w ten sposób mam to podłączone.

Chyba znalazłem przyczynę, a przynajmniej jedną z przyczyn. Okazuje się, że miałem przerwę na linii ROMCS - najprawdopodobniej niekontaktujący lut na przelotce. I to niekontaktujący w ten sposób, że akurat dał prawidłowy odczyt, gdy robiłem tekst ciągłości multimetrem.

Wygląda na to, że linia ROMCS wisząc w powietrzu był interpretowana przez flash jako stan niski, dzięki czemu program się wykonywał. Jednak w momencie korzystania z RAM-u dochodziło do konfliktu na magistrali.

Poprawiłem to połączenie i zniknęły "brzydkie" stany z linii danych w momencie korzystania z pamięci RAM - teraz mam już ładne, jednoznaczne stany niskie lub wysokie.

Niemniej program korzystający z flasha nadal nie chce działać. Możliwe, że mam jeszcze inny problem. Mam tylko nadzieję, że nie uszkodziłem pamięci...

Ok, problem ze stosem okazał się mieć banalne podłoże - dałem include w złym miejscu w stosunku do dyrektywy ORG, przez co funkcja do której robiłem CALL z osobnego pliku znajdowała się pod adresem niemającym sensu.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required