Pamięć nadpisuje stos (choć powinno by

Nie myślałeś aby napisać mały emulator cpu (ba, ukraśc gotowca, jest ich zilion) + trywialny emulator hardware (tych przycisków) i debugować in vitro, co tam się dzieje? Jak już masz transakcje cpu typu "zapisz bajt" i "odczytaj bajt" to napisanie kawałka kodu który udaje że jest przyciskiem, nie jest chyba jakieś strasznie trudne.

Powoli myslę nad zrobieniem małego komputera na CP/M (i mam nadzieje GEMa, jak mi się uda), ale wiem że pracę zaczne *wirtualnie*, czyli piszać emulator cpu, hardware i to będzie moje miejsce do debugu, nie fizyczne hardware, ono powstanie później lub równolegle...

To może wskazywać np. na to że nie wracasz z przerwania (masz jakieś?) lub się nie wyrabiasz i po jakims czasie przekręca się stos sprzętowy. Taka luźna myśl. Co prawda widzę CLI na początku maina, ale może cos przeoczyłem.

Jeszcze jedno: nie przestawiasz gdzieś procesora w tryb BCD?

I jeszcze jedno: Masz gdzieś podpięte SO (pin cpu)?

Sorry, ale review kodu nie zrobie... za duży :)

Systemy na 6502 mają tylko jeden wektor przerwań. Linia INT jest zwierana do masy przez poszczególne urządzenia zgłaszające przerwania, za pomocą wyjść typu OC. W kodzie obsługi przerwania trzeba po kolei odpytać wszystkie urządzenia i zdjąć flagi. Jest więc tylko jedna procedura obsługująca przerwanie, zakończona instrukcją RTI, więc program wraca z przerwania. Na początku procedury zapisuję na stosie zawartość rejestrów A oraz X (tylko z nich korzystam) a przed powrotem je przywracam.

Wszystkie funkcjonalności związane z przerwaniami działają poprawnie.

Co masz na myśli?

W 6502 CLI to instrukcja "clear interrupt DISABLE", natomiast SEI oznacza "set interrupt DISABLE". Czyli CLI włącza przerwania, SEI je wyłącza. Odwrotnie niż w AVR-ach czy PIC-ach.

Świadomie nie. Cały program zawiera tylko kilka asemblerowych fragmentów (m.in. procedura obsługi przerwań) i jestem pewien, że w żadnym z nich nie stosowałem instrukcji SED.

Podciągnięty do plusa.

Przerwanie jest przerywane przerwaniem. Dośc częsta wpadka generująca rózne problemy, podobne do opisanych.

Wiem, ale nie byłem pewny czy z przerwań korzystasz.

No niezupełnie, ogólnie rzecz biorąc jest IRQ i NMI, mają osobne wektory.

Nawet w przypadku 6502? Jest jedno wejście INT. Jeśli kolejne urządzenie zgłosi przerwanie przed skasowaniem flagi poprzedniego nic się nie stanie, bo system nie będzie miał jak wiedzieć, że przyszło kolejne przerwanie. Dopiero po opuszczeniu procedury obsługi przerwania zostanie ona wywołana ponownie.

Nie jestem pewien co do sytuacji, kiedy kolejne przerwania przychodzi dopiero po zdjęciu flagi poprzedniego (urządzenie peryferyjne odłącza wejście INT od masy) ale przed wykonaniem RTI.

Kwestię NMT pomijam, bo wcale z niego nie korzystam.

Swoją drogą, jest jakiś prosty sposób na ocenienie użycia stosu sprzętowego 6502 przez wywołania funkcji C? Może faktyczne mam za dużo zagnieżdżeń? Niby argumenty i zmienne lokalne są przechowywane na stosie programowym, ale jednak dresy powrotu ciągle trafiają na sprzętowy...

Tylko z drugiej strony w takim wypadku manipulowanie rozmiarem buforów nie miałoby wpływu na sytuację...

Codzi o zagnieżdzenie NMI/IRQ. Jeśli nie używasz jednego z nich to może to fałszywy trop.

Ale oceń jaki możesz mieć najdłuższy stos głównego programu i jaki możesz miec najdłuższy stos w przerwaniu, shit happens.

Emulatorem, własnym.

Np, jeden z ziliona:

Narzędzi do formalnej weryfikacji stosu na 6502 nie znam, wydaje mi się jednak że widziałem takie do clanga jako ciekawostkę. Ale to Ci się nie przyda, poza jakimiś hobbystycznymi eksperymentami nie ma backendu do

Możliwe że problem tylko tak się objawia, to nie jest przyczyna.

Na ile ufasz, że kod generowany przez kompilator, jest prawidłowy?

Też tak myślę. Zupełnie nie znam 6502 ani tego, jak Twój kompilator alokuje pamięć, ale jesteś w stanie zrobić i wpleść w newralgiczne miejsca test, który wypluje na dowolne wyjście informację, jeśli stos (wskaźnik stosu) niebezpiecznie zbliży się do wskaźnika sterty?

Używasz tam w ogóle dynamicznej alokacji pamięci, czy wszystko jest statycznie? Jeśli używasz dynamicznej alokacji, to masz pewność, że nie masz żadnych wycieków?

Takie problemy, o jakich mówisz (wszystko działa, dodaję prostą funkcjonalność i wszystko zaczyna się losowo sypać), miałem w niewielkim projekcie na AVR i wynikały właśnie z nadpisywania sterty przez stos. Projekt niewielki, ale okazało się, że wystarczający.

Ok. Wygląda na to, że udało mi się namierzyć źródło problemu. Kod obsługujący przerwanie wywoływał funkcję. która zawierała polecenia rozkazy SEI/CLI (zabezpieczenie przed uszkodzeniem zawartości zmiennej przez przerwanie). Jednak w przypadku 6502 użycie tych rozkazów w trakcie obsługi może spowodować wystąpienie kolejnego przerwania, a w efekcie nadpisanie stosu sprzętowego i niestabilne działanie.

Przepisałem kod w ten sposób, żeby pozbyć się wywołania tej funkcji, a więc i SEI/CLI. Teraz urządzenie zdaje się działać poprawnie.

W drugim projekcie tego kodu nie było, więc działało poprawnie.

Użytkownik "Atlantis" napisał w wiadomości grup dyskusyjnych:5f749a85$0$544$ snipped-for-privacy@news.neostrada.pl...

Jesli dobrze rozumiem - to niechcacy odblokowalo przerwania w procedurze obslugi przerwania? I sie przerwania nakladaly, i stos rosl ?

To by tlumaczylo zachowanie, ale ... obsluga przerwania powinna byc krotka, i szansa zlapania drugiego przerwania niewielka, a przeciez dwa jeszcze nie powinny wywrocic programu. Musialo sie to czesciej zdarzac, czyli obsluga przerwania za dluga, i/lub przerwania czeste.

No chyba, ze krytyczne bylo samo przerwanie obslugi i niekontrolowana zmiana uzywanych tam zmiennych.

Pamiec mi juz zawodzi - ta flaga nie jest w statusie 6502 ? Moze da sie zamiast CLI przywrocic poprzedni stan flagi ...

J.

Pewnie tak, stos wywołań rósł, stos używany przez kompilator na zmienne lokalne funkcji obsługi przerwań też rósł...

Jeśli tam jest jedno przerwanie do wszystkiego, to może nie może być tak bardzo krótka, a i przerwanie często się pojawia (np. od timera?).

Może ta obsługa klawiatury jest w przerwaniu. Do tej pory się wyrabiało, ale doszło trochę cykli i przestało.

Tzn. ISR nie było wielobieżne (reentrant)? Tak też może być...

Zapewne tak właśnie było. Konkretnie winę za przyrost programowego stosu musiała ponosić t sama wywoływana funkcja, w której znalazły się polecenia SEI/CLI. Wygląda na to, że wprowadzenie tej jednej zmiany usunęło problem. Urządzenie chodzi już przez pół dnia i nie widzę żadnych przejawów niestabilnego działania. Nie było fałszywych wciśnięć przycisków i nie zresetowało się ani razu. ;)

Tak, tm jest jedno przerwanie od wszystkiego, bo system nie posiada żadnego kontrolera priorytetów przerwań. W tym jednym przerwaniu trzeba odpytać po kolei wszystkie urządzenia. W chwili obecnej korzystają z tego trzy urządzenia: RTC (raz na sekundę), timer (co 20 ms) i UART (kiedy przyjdzie nowy znak).

Trzy przerwania sprzetowe polaczone bramka OR czy tam AND, AND "na drucie" ?

Pomysl czy tam nie bylo sytuacji:

-jeden z ukladow wysterowuje linie IRQ,

-w trakcie obslugi, zanim obsluzysz wlasciwy chip, wykonuje sie instrukcja CLI,

-poniewaz linia IRQ jest ciagle aktywna - procesor natychmiast wywoluje obsluge przerwania,

-i tak w kolko, dopoki program obslugi nie dojdzie do wlasciwego chipu i nie zgasi przyczyny przerwania, lub chip sam nie zdeaktywuje.

Tylko to raczej blyskawicznie by wywalalo program, a nie tak raz na pewien czas ...

J.