Dziwne zachowanie R65C51 + MAX232

Pracuję właśnie nad pewnym projektem retro, składanym ze starych części. Pracą urządzenia steruje mikroprocesor WDC65C02, jest też trochę innych peryferiów, m.in UART R65C51. Urządzenie zdaje się pracować prawidłowo, uruchomiłem większość podzespołów, problemy zaczęły się właśnie przy w przypadku portu szeregowego.

1) Sam R65C51 zdaje się działać prawidłowo. Kiedy podpiąłem go do przelotki USB-UART (linia CTS tymczasowo ściągnięta do masy) wszystko działa prawidłowo. Urządzenie przechodzi inicjalizację i na komputerze mogę odbierać wysyłane przez nie komunikaty. Transmisji w drugą stronę jeszcze nie testowałem. 2) Urządzenie inicjuje się także wtedy, gdy do R65C51 nie jest podłączony ani konwerter USB-UART, ani RS232. 3) Jednak gdy włożę w podstawkę układ MAX232, urządzenie nie przechodzi inicjalizacji. Najwyraźniej zawiesza się właśnie na inicjalizacji R65C51. Dopiero podłączenie do komputera za przez kabel RS232 naprawia sytuację - wtedy urządzenie znów zaczyna się prawidłowo uruchamiać, a w terminalu pojawiają się komunikaty.

Sęk w tym, że UART ma służyć do konfiguracji i diagnostyki urządzenia. Nie mogę sobie pozwolić na sytuację, żeby jego uruchomienie wymagało podpięcia do komputera.

Ktoś ma jakiś pomysł odnośnie tego, co robię źle?

Kod inicjujący UART jest relatywnie prosty:

void mos6551_init (void) { //initialise 6551 ACIA ACIA_RES = 0xFF; //soft reset (value not important) ACIA_CMD = 0x0B; //set specific modes and functions ACIA_CTL = 0x1E; //8-N-1, 9600 baud }

Za pomocą CC65 kompiluje się do następującego kodu asemblerowego:

; --------------------------------------------------------------- ; void __near__ mos6551_init (void) ; ---------------------------------------------------------------

.segment "CODE"

.proc _mos6551_init: near

.segment "CODE"

lda #$FF sta $6001 lda #$0B sta $6002 lda #$1E sta $6003 rts

.endproc

Reply to
Atlantis
Loading thread data ...

W dniu 13.08.2020 o 07:59, Atlantis pisze:

Na szybko i na moje oko to poza tx i rx masz podpięte pewnie inne sygnały.

Pozdrawiam

DD

Reply to
Dariusz Dorochowicz

Tak, MAX232 obsługuje jeszcze dwie linie: RTS (podłączony do pinu 7 gniazdka RS232) oraz CTS (podłączony do pinu 8). Połączenie z komputerem jest wykonane przez scrossowany kabel. Wejścia DSR i DCD są na stałe połączone z masą. Wyjście DTR nie jest do niczego podłączone.

Reply to
Atlantis

No to jak nie masz tam nic podłączonego to nie dziwne że nie działa. Zewrzyj RTS z CTS albo je programowo ignoruj (jak się da, zapewne się da) i pewnie będzie lepiej. Oczywiście chodzi o zwarcie po jednej stronie bez przeprowadzania kabla do komputera.

Pozdrawiam

DD

Reply to
Dariusz Dorochowicz

Bardzo podejrzane. Włożenie MAX232 nic nie powoduje. Nawet stan lini wejściowych nie powinien sie wyraźnie zmienić.

Sprawdzałeś co się stanie jak podniesiesz linie wejściowe do +5V przez jakieś rezystory? Też się "psuje"?

Co to znaczy "urządzenie nie przechodzi inicjalizacji". W sensie zawiesza się na jakiejś pętli?

Rozumiem że brałeś kod i schemat z tego miejsca?

formatting link

Reply to
heby

Dnia Thu, 13 Aug 2020 07:59:06 +0200, Atlantis napisał(a):

Tu nie ma nic, co by moglo sie zawiesic. Szukaj gdzies dalej.

Moze dalej program na jakis stan linii czeka, moze przerwania sie aktywuja, moze stale cos odbiera.

Niepodlaczone linie kosci powinny miec stan "1" czyli nieaktywne, ale Max232 tez powinien na nich "1" ustawic, jesli kabla brak.

A moze wlasnie program chce wyslac cos na port, wiec czeka na linie CTS ?

J.

Reply to
J.F.

Teraz widzę, że urządzenie prawdopodobnie zawiesza się na pierwszej probie wysłania czegokolwiek - w tym wypadku będzie to komunikat oznajmujący koniec inicjalizacji peryferiów. Do pętli głównej kod nie dochodzi, bo nie zawarty w niej kod nie wykonuje się ani razy (a trochę różnych rzeczy wykonywał zanim w ogóle zaczynał korzystać z UART-a).

Czyżby stan wysoki na CTS powodował, że flaga oznaczająca zajęty bufor nadawczy nigdy nie była zerowana? Moja procedura nadawania znaku faktycznie czeka na jej zwolnienie...

Czy mogę programowo sprawdzić status CTS, aby w przypadku stanu wysokiego program po prostu rezygnował z próby nadawania? Czy też jedyną opcją jest przerobienie układu i zrezygnowanie z obsługi CTS/RTS?

Dzięki za podesłanie linku. Zerknięcie na schemat uświadomiło mi, że miałem trywialny błąd -zamiast dwóch kondensatorów między pinem 2 i VCC orz pinem 6 i masą miałem jeden kondensator między tymi pinami. To jednak nie to było powodem opisywanych problemów - po usunięciu błędu problem nadal występuje.

Reply to
Atlantis

CTS/RTS ma sens *jedynie* kiedy twoje urządzenia są zbyt powolne aby odbierać znaki jeden po drugim.

Jak ustawisz asercje na RTS/CTS (+5V bodaj) to nagle się główna pętla odblokuje?

Reply to
heby

Jeszcze jedno: mimo że cpu nie ma debugu, to mógłbyś wpiąć się w linie adresowe i ocenić gdzie się miota. Może z pomocą analizatora ustalisz jaki kod jest wykonywany w pętli, albo choć kilka starszych bitów adresu uda się zidentyfikować (zwróć uwagę na pin SYNC).

Osobiście wziąłbym jakiś softwareowy emulator tego cpu, wrzucił kod i napisał jakiś trywialny emulator scalaka do transmisji szeregowej... ale to robota dla programisty. Ma to zaletę że można debugować bez hardware, w czystych i powtarzalnych warunkach.

Reply to
heby

Atlantis snipped-for-privacy@wp.pl napisał(a):

Wysoki stan na pinie CTS oznacza, że drugie urządzenie nie jest gotowe do odbioru. Nadawanie nie rozpocznie się dopóki CTS nie znajdzie się w stanie niskim.

O ile dobrze rozumiem, zostałeś zaskoczony działającą funkcją sprzętowej kontroli przepływu. Nie znam tego procka, więc nie wiem czy tak jest konfigurowany UART po resecie czy też ustawia to kod inicjalizacyjny. Z komentarzy to nie wynika.

Stan CTS możesz oczywiście sprawdzać programowo i ewentualnie rezygnować zamiast czekać. Będzie to trochę wbrew standardowi, bo wysoki CTS oznacza "wyślij mi te dane później" a nie rezygnację. Ale i tak jest kwestia czy ta sprzętowa kontrola przepływu jest Ci do czegoś potrzebna. Jeśli port szeregowy ma robić za konsolę, to ja bym to wyłączył.

Reply to
Grzegorz Niemirowski

Wszystko powinno sie udac zznalezc ... o ile analizator ma wystarczajaco duzo kanalow :-)

Jesli dobrze zgadujesz z tym CTS, to wystarczy ustawic go odpowiednio na kablu i zobaczyc czy program pojdzie dalej.

Dobry emulator terminala powinien miec mozliwosc sterowania liniami DTR i RTS, to na skrosowanym kablu by sie szybko sprawdzilo, ale ... kto zna dobry wspolczesny emulator ? :-( A tak zostaje oscyloskop i srubokret do zwierania nozek :-)

J.

Reply to
J.F.

Jak ma za mało, to zawsze można zrobić protezę z arduino:

formatting link

Reply to
Zbych

W dniu 14.08.2020 o 11:12, J.F. pisze:

To nie zgadywanie tylko "prawie na pewno" - bez sprawdzenia tego w ogóle nie ma sensu robienie czegokolwiek innego. Szansa na inny powód jest bardzo nikła. Kwestia znalezienia właściwego rozwiązania.

Ale co chcesz sprawdzać? I lepiej lutownica, nie śrubokręt. Ten potrafi kiepsko zewrzeć. Albo inny kod do inicjalizacji układu. Pewnie ze dwa bity inne będą - brak kontroli przepływu i tyle. Zwarcie RTS z CTS będzie miało ten sam skutek.

Pozdrawiam

DD

Reply to
Dariusz Dorochowicz

6502 ogarniałem za pomocą najtańszego klona Saleae, natomiast przy problemie "coś się zapętliło" czasami wystarczy oscyloskop dwukanałowy ... i odrobina szczęscia aby pętla nie była za daleka. 6502 ma pin SYNC dzięki czemu te dwa kanały są skrajnie upierdliwe, ale da się zdebugować.
Reply to
heby

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.