Elektroda.pl
Elektroda.pl
X
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

Atmega 162 + FT232RL = problemy z komunikacją

ja_fryta 03 Nov 2010 09:24 4886 31
Computer Controls
  • #1
    ja_fryta
    Level 19  
    Sytuacja wygląda tak.
    mój uC komunikuje się z komputerem poprzez układ FT232 na wirtualnym porcie COM.
    Wszystko pracuje sprawnie zaraz po włączeniu.
    Po nieokreślonym upływie czasu uC jest nadal w stanie wysyłać dane do komputera ten jednak przestaje odpowiadać (lub procesor odbierać).
    Problem rozwiązuje wyłączenie na chwile zasilania na uC (tylko tu), FT232 cały czas jest zasilany i otwarty jest programowo.
    Takie resety niestety trzeba wykonywać 1 - 2 dziennie.
    Czy ktoś spotkał się z podobnym zachowaniem.
    Aha dodam jeszcze że takie samo urządzenie pracuje gdzie indziej i takie problemy nie występują.
  • Computer Controls
  • #2
    mirekk36
    Level 42  
    ja_fryta wrote:
    Czy ktoś spotkał się z podobnym zachowaniem..


    Tak, ja bardzo często spotykam się z takim zachowaniem. To wręcz bardzo częste zjawisko. Dochodzi do niego co jakiś bliżej nie określony odcinek czasu. A powód tego zjawiska jest zawsze ten sam. Dzięki czemu można w 100% wyeliminować to zjawisko.

    Gdzie spotykam się z tym zjawiskiem?

    ano najczęścien na elektrodzie, gdzie co jakiś bliżej nie określony odcinek czasu, ktoś zakłada dokładnie taki lub podobny wątek jak ten.

    Jaki jest powód(-y) tego zjawiska?

    1. Brak poprawnego oprogramowania mikrokontrolera (najczęściej - 70% przypadków.

    2. Brak poprawnie napisanego oprogramowania na PC jeśli to nie jest jakiś gotowy terminal oczywiście (ok 15% przypadków)

    3. Błędne połączenia, złe filtrowanie zasilania zarówno uC jak i FT232, lub tragicznie wykonane PCB (chodzi nie tylko o lutowanie ale i o sam projekt, schemat itp) - ok 15% przypadków


    Masz zatem pełną odpowiedź na tak zadane pytanie.

    Można to w 100% naprawić - wystarczy tylko poprawić to co jest zrąbane w jednym albo wszystkich z wymienionych wyżej punktów. Sytuacja zawsze powtarzalna, tzn jak się to poprawi to zawsze poprawnie wszystko działa.
  • #3
    ja_fryta
    Level 19  
    Skoro działa w innym miejscu a w tym jednym konkretnym to chyba 1 i 2 odpadają.
    Po zatym sytuacja chyba nietypowa skoro tylko na uC Rx pada.
    Co do jakości PCB to wykonuje sobie w http://www.prototypy.com/ co do projektu to pewności nie mam (zaprojektowałem sam).
  • Computer Controls
  • #4
    mirekk36
    Level 42  
    ja_fryta wrote:
    Skoro działa w innym miejscu a w tym jednym konkretnym to chyba 1 i 2 odpadają.

    Ja myślę, że słusznie zauważyłeś - dodając to słówko "chyba". To już jakiś postęp. I nie myśl, że się czepiam - ale argumenty typu, że "coś w innym miejscu działa a w tym miejscu nie" - do mnie w ogóle nie trafiają i są wręcz nieporozumieniem. Jeśli mi coś w jednym miejscu działa a w innym nie - to szukam we własnym oprogramowaniu problemów po jednej i drugiej stronie, szukam gdzie mogłem popełnić błąd w projekcie własnym - a nigdy nie szukam winowajcy w źle/wadliwie działającym procesorze tudziesz innej części elektronicznej.


    ja_fryta wrote:
    Po zatym sytuacja chyba nietypowa skoro tylko na uC Rx pada.
    Bardzo typowa sądząc po takim opisie problemu że "Rx pada" . Uwierz nie czepiam się słówek, po prostu, jesteś kolejną osobą, która zamiast dokładnie sprawdzać co sama zrobiła i szukać błędu u siebie zaczyna podejrzewać układy scalone.
    ja_fryta wrote:
    Co do jakości PCB to wykonuje sobie w http://www.prototypy.com/ co do projektu to pewności nie mam (zaprojektowałem sam).
    No to już bardzo świadczy o tym, że kolega nie do końca chyba orientuje się w temacie (przepraszam jeśli się mylę) ale co ma wspólnego wykonywanie PCB nawet w jakiejś amerykańskiej agencji NASA, jeśli sam projekt jest skopany pod względem choćby prowadzenia ścieżek, zasilania, filtrowania zasilania i tak mógłbym jeszcze długo wymieniać. Żadna firma wykonująca płytki nie pomoże ci w tym, ona wykona nawet najbardziej źle zaprojektowaną płytkę bo ich zadaniem jest wyprodukować PCB a nie analizować jej poprawność pod względem merytorycznym i to jeszcze nie mając schematu ani wiedzy o zamiarach autora ;)
  • #5
    ja_fryta
    Level 19  
    Nie szukam winy gdzie indziej i na produktywna krytykę jestem otwarty.
    Próbuje rozwiązać swój problem metodą eliminacji i rad forumowiczów.
    Nie podejrzewam wadliwego układu odnośnie mojej wypowiedzi, chciałem tylko jasno zasygnalizować co nie działa.
    Odnośnie pcb napisałeś że winą może być tragiczne wykonanie i ja tutaj jasno zaznaczyłem że jakość wykonania samego PCB jest dobra podobnie jak lutów, a nie jestem pewien tylko czy nie popełniłem błędu projektowego.
  • #6
    mirekk36
    Level 42  
    No to dlatego zrozum, że łatwiej coś poradzić czy podpowiedzieć w takim temacie, gdy jego autor poda jakieś konkrety a nie tylko takie porównanie, że "tu działa a tam nie" to znaczy że mój program czy projekt jest ok.

    Gdybyś poparł to jakimś chociaż schematem, fragmentami programu w których wydaje ci się chociaż, że mogą się pojawiać błędy, napisał coś dokładnie w ogóle o samym układzie , może pokazał płytkę albo jej fragmenty jeśli to tajemnica (co rozumiem)

    to można byłoby bez żadnej krytyki, po prostu wspólnie poszukać odpowiedzi na pytania co może być nie tak - rozumiesz ?

    A błędy projektowe? ... każdemu się zdarzają - to nie jest nic zdrożnego.
  • #7
    ja_fryta
    Level 19  
    Zamieszczam zrzut ekranu mojego pcb.
    Atmega 162 + FT232RL = problemy z komunikacją
    Na samej górze jest wyjście na klawiaturę 4x3, niżej podpisany jest wyświetlacz. Zielone ścieżki są w warstwie bottom tak samo jak mega i wszystkie elementy smd. Na dole jest wyście z gniazdem usb poprzez które łączy się z FT232 a ten następnie z komputerem.
    Nie wiem jakie informację mógł bym jeszcze zamieścić proszę o uwagi.
  • #8
    hotdog
    Level 26  
    podobnie jak mirekk36 z tą różnicą, że na 99%, uważam że masz błąd w sofcie na uC.

    Akurat też kilka dni temu miałem problem pokrewny, w którym właśnie kolega mirek mi pomógł.

    Piszesz go na przerwaniach? W jakim języku? Nie wyłączasz nigdzie nadajnika, albo coś?
  • #9
    mirekk36
    Level 42  
    No zdecydowanie przydałby się schemat tego a nie tylko PCB ale już chyba z takiego suchego widoku PCB wynika kilka wniosków i pytań:

    1. Powiedz mi jak to jest? - masz na płytce gniazdo USB ale wyjścia D+ oraz D- podłączone są wprost do wejść procka TxD oraz RxD - czyli ty używasz tego tylko do połączenia szeregowego RS232 za pomocą kabla USB z przejsciówką na FT232RL tak ??????

    2. a ta przejściówka FT232 zrobiona jest przez ciebie ???? jeśli tak to jak ona wygląda ???? Proponowałbym też jej schemat pokazać.

    3. czy ty w ogóle używasz filtrowania napięcia zasilania ???? Niestety z takiego widoku (bez schematu) to ciężko stwierdzić ale wydaje mi się że w ogóle NIE MASZ filtrowania zasilania - a jeśli dobrze myślę to już pierwsza podstawa do tego żeby z twoim układem działy się cuda-dziwy (i to wcale nic nie znaczy że jeden działa a drugi nie)

    tak więc teraz schemat albo 2 schematy mogłyby już ostatecznie dużo wyjaśnić - o ile chcesz się czegoś dowiedzieć co źle robisz? Bo jesli uważasz, że masz wszystko dobrze i idealnie gdyż jeden układ działa to w zasadzie nie powinno być tego tematu albo rzeczywiście szukaj problemów w prockach czy scalakach FT232.

    Dodano po 3 [minuty]:

    oooo a zresztą proszę poczytaj sobie ten temat:
    https://www.elektroda.pl/rtvforum/topic1809320.html

    tutaj kolega podobnie jak ty (kilka dni temu), był w 10000% przekonany że on zrobił wszystko dobrze a procesory AVR się wciąż zawieszają, latch-up'ują i nie wiadomo jakie jeszcze cuda dziwne. Pojechał więc ostro po AVRach, że są niby nie odporne na azakłócenia (jak gdzieś słyszał), że lepiej będzie ATtiny2313 zastąpić może jakimś procesorem ARM !!!!!! szok .... a zobacz jak to się skończyło - to może być ciekawa dla ciebie lektura - poważnie.
  • #10
    ja_fryta
    Level 19  
    Ja nie jestem przekonany do niczego. Przygodę z elektroniką dopiero zaczynam i szukam rad. Teraz jestem w pracy ale jak wieczorem wrócę do domu to zamieszczę więcej informacji.
  • #11
    ja_fryta
    Level 19  
    odp 1.
    Połączenie wygląda tak. Z gniazda na PCB które zamieściłem przewodem USB łącze się bezpośrednio z FT232. D+ i D- minus wykorzystuje jako Rx i Tx. Używam do połączenia kabla szeregowego. Przewód zasilania jest wykorzystywany jako 5V a masa jest w ekranie (tylko w ekranie). Potrzebny był mi jeszcze jeden przewód do podłączenia zewnętrznego czujnika i do tego wykorzystuje przewód masy. Przewody które wykorzystuje (3 m) mają masę jako taką siateczkę cienkich przewodzików i dodatkowo wpleciony w nie przewód taki sam jak pozostałe. Takie rozwiązanie chyba nie stanowi problemu ?

    odp 2.
    Przejściówka tak też jest wykonania prze zemnie, zgodnie z schematem z noty katalogowej.

    odp 3.
    Schematu niestety nie wykonałem. Wydawało mi się że jest to zbyteczne bo układ jest bardzo prosty.
    Odnośnie filtrowania napięcia zasilania to korzystam z zasilacza stabilizowanego 5v/2A (pewnie na wyjściu są jakieś elektrolity), dalej w samym urządzeniu mam dwa kondensatory 10uF i 100nF między masą i Vcc. Do masy ściągam też nóżki od kwarcu (8MHz).

    Atmega 162 + FT232RL = problemy z komunikacją Atmega 162 + FT232RL = problemy z komunikacją
    Atmega 162 + FT232RL = problemy z komunikacją
  • #12
    hotdog
    Level 26  
    ja_fryta wrote:
    Do masy ściągam też nóżki od kwarcu (8MHz).


    Ale chyba nie rezystorami?

    Przeleciałem na szybko jeszcze raz przez temat, ale już nie jestem pewien - czy program działa Tobie poprawnie na innych "wersjach" tego urządzenia?

    Dodano po 2 [minuty]:

    W sumie już widzę na zdjęciu PCB że są to kondensatory.
  • #13
    ja_fryta
    Level 19  
    Tak dzieje się to tylko w jednym miejscu.
  • #14
    hotdog
    Level 26  
    Czyli masz kilka identycznych egzemplarzy tego samego urządzenie z tym samym programem i tylko jedno szwankuje?

    To zamień jakieś dobre z tym nie działającym i zobaczysz czy to kwestia "otoczenia" czy samego urządzenia.
  • #15
    ja_fryta
    Level 19  
    Tak mam kilka i jak podmieniłem problem był ten sam. Jak sprawdzałem w domu oba urządzenia działały poprawnie.
  • #16
    hotdog
    Level 26  
    nie jasno napisałeś.

    Czyli problemem jest otoczenie urządzenia a nie samo urządzenie? Może to kwestia zasilania? Może pozamieniaj zasilacze i zobacz czy problem istnieje dalej. Upewnij się też, że masz włączony BOD.

    Czy w tym otoczeniu szwankującym są jakieś wysoko zakłócające urządzenia (silniki itp)?
  • #17
    ja_fryta
    Level 19  
    To jest sklep jest tam dużo lodówek, chłodziarek, lotków, terminali płatniczych wszelkiej maści, itp. Nie wiem czy te urządzenia są zakłócające ale z takimi ma styczność.

    Co masz na myśli z czy mam włączony bod ?
  • #18
    hotdog
    Level 26  
    We fusach masz coś takiego jak Brown Out Detection, czyli detekcja spadku napięcia zasilania poniżej jakiejś tam wartości. Zapobiega to różnym dziwnym rzeczom jakie mogły by się stać. Kiedyś rozwijałem urządzenie w którym zapomniałem to włączyć, to bootloader potrafił się sam włączyć i przeprogramować całą stronę flasha.

    Takie otoczenie na pewno nie jest idealne do pracy urządzeń elektronicznych, no ale też nie jest najgorsze.

    Możesz spróbować urządzenie zamknąć w metalowej, zmasowanej obudowie (np wsadź w obudowę komputera). Tak sprawdzisz czy zewnętrzne zakłucenia powodują te zwisy.

    Poza tym ekran USB masz połączony z masą urządzenia?

    Jak masz napisany soft? Przerwania czy pooling? Jaki język BASCOM, C czy ASM?

    Nie bardzo wiem co więcej podpowiedzieć.
  • #19
    ja_fryta
    Level 19  
    Pisałem w C na przerwaniach.
    Fragment kodu odpowiedzialny za to

    
    ISR(SIG_USART0_RECV)
    {
    	unsigned char s = USART0_Receive();
    	if((CHECKBIT(command, COMMAND_STATUS_OCZEKIWANIE)))//sprawdza czy zaczyna nowa komende
    	{
    		command_in = 0;
    		CLEARBIT(command, COMMAND_STATUS_OCZEKIWANIE);
    		buffer_comand[command_in] = s;
    		command_in++;
    	}
    	else
    	{
    		if(s == 13)
    		{
    			SETBIT(command, COMMAND_STATUS_WYKONAC);
    		}
    		else
    		{
    			if((command_in + 1) < 20)
    			{
    				buffer_comand[command_in] = s;
    				command_in++;
    			}
    			else
    			{
    				SETBIT(command, COMMAND_STATUS_WYKONAC);
    			}
    		}
    	}
    }
    
    unsigned char USART0_Receive( void )
    {
    	/* Wait for data to be received */
    	while ( !(UCSR0A & (1<<RXC0)) );
    	/* Get and return received data from buffer */
    	return UDR0;
    }
    
    void USART0_Init( unsigned int ubrr )
    {
    	//ubrr = 25;
    	/* Set baud rate */
    	UBRR0H = (unsigned char)(ubrr>>8);
    	UBRR0L = (unsigned char)ubrr;
    	/* Enable receiver and transmitter */
    	UCSR0B = (1 << RXCIE0) | (1 << RXEN0) | (1 << TXEN0);
    	/* Set frame format: 8data, 2stop bit */
    	UCSR0C = (1<<URSEL0)|(1<<USBS0)|(3<<UCSZ10);
    }


    Fusy które mam zaznaczone
    BOOTSZ1
    BOOTSZ0
    SUT0
    CKSEL1
    CKSEL0
  • #20
    hotdog
    Level 26  
    to powinieneś zaznaczyć BODLEVEL0 i BODLEVEL1, wtedy będziesz miał BOD'a ustawionego na 4,3V. Jeżeli napięcie spadnie poniżej 4,3V to procesor się zresetuje. Nie wiem czy to jakoś szczególnie Tobie tutaj pomoże, ale IMO każde urządzenie powinno mieć BOD'a włączonego. Lepiej żeby urządzenie się zresetowało, niż żeby zaczęło działać nieprzewidywalnie.

    Widzę że wysyłasz dane bez przerwania które działa poprawnie. A nie blokujesz gdzieś w swoim programie przerwań przez cli? A może urządzenie tak naprawdę odbiera pakiet, tylko program główny wisi gdzieś i nie wykonuje pleceń tak jak powinien? Żeby to sprawdzić zrób toogle diody w przerwaniu od SIG_USART0_RECV (w sumie ISR powinieneś wykorzystać z USART_RXC_vect, ale to raczej też nie ma znaczenia dla kodu wnikowego).

    Jak już zrobisz ten toogle to zobaczysz czy dioda mruga, będziesz wiedział czy program wyłączył przerwania, czy główny wisi sobie gdzieś tam.
  • #21
    nostromo
    Level 14  
    Wszystko pięknie, ale jaką częstotliwością jest taktowany mikroprocesor i jaką prędkość transmisji stosujesz?
  • #22
    ja_fryta
    Level 19  
    Zewnętrzny oscylator 8MHz
    Baud - 19200
  • #23
    ja_fryta
    Level 19  
    Nie wywołuje cli (nie wiem co to jest).
    Dostałem kiedyś radę radę żeby dodać sei w main i tak też zrobiłem.
    Mój program działa tak mam pętle while(1) w której sprawdzam klawiaturę czy nie została wciśnięta i jeżeli tak to tylko ustawia odpowiednie pola to samo dzieje się w przerwaniach. Gdy odbieram jakiś znak to dodaje go do tablicy i ustawiam odpowiednią flagę. Na sam koniec w głównej pętli sprawdzam flagi i wykonuje odpowiednie operacje.

    BOD - ok dodam tylko nie jestem pewien czy to pomoże zasilacz jest na tylko 3m przewodzie. Jak sprawdzałem to mam 5.05 - 5.15 na układzie.
  • #24
    hotdog
    Level 26  
    tak też napisałem że nie sądzę żeby to miało tutaj wpływ, ale każde urządzenie powinno mieć go włączonego. Jak włączasz zasilacz do sieci myślisz że od razu on osiąga napięcie 5V? Jak tak to jesteś w błędzie. Wyobraź sobie że procesor zacznie pracować już przy 2,5V, ale może zrobić coś "dziwnego". Dlatego BOD powinien być włączony wszędzie tam, gdzie nie ma oddzielnego układu resetu. Oczywiście tak jak napisałem nie sądzę żeby to miało jakiś wpływ tutaj.

    Zrób tak jak napisałem. Dodaj toogle diody w przerwaniu od RXC. będziesz wiedział, czy program poprawnie wchodzi w przerwanie, czy sobie gdzieś tam wisi.
  • #25
    ja_fryta
    Level 19  
    Nie wiem czy to mi się uda (z tym toogle). U mnie w domu to się nigdy nie stało a tu bym mógł siedzieć i sprawdzać to nawet 24h natomiast w w.w. sklepie całego dnia nie mam możliwości spędzić. Tutaj problem raczej będę musiał rozwiązać metodą prób i błędów. Może poradzisz mi co warto zmienić ja wprowadzę parę zmian i po jakimś czasie zobaczymy czy się poprawiło.
    Na pewno BOD wprowadzę. Słyszałem jeszcze coś o watchdog ale nie wiem jeszcze za bardzo co to jest będę musiał doczytać.
  • #26
    hotdog
    Level 26  
    No ale to ogólnie chyba nie problem. Nawet jak ktoś inny jest przy sterowniku to zawsze może sprawdzić czy po zawieszeniu dioda miga.

    Ja bym poradził zrobić najpierw tylko ten toogle. To IMO dużo powie. Poza tym BOD obowiązkowo, do tego możesz urządzenie zamknąć w zmasowanej, metalowej obudowie.
  • #27
    ja_fryta
    Level 19  
    Dostałem wiadomość że innym miejscu to się nie dzieje. Mam w sumie 5 urządzeń i problem występuje w 2. Znaczy się nie urządzeniach a miejscach tak jak pisałem. Jak przekładam je to te nie działające działają i na odwrót.
    A z tą diodą to muszę to jakoś wymyślić bo poważnie to może być problem.
  • #28
    ja_fryta
    Level 19  
    Dałem BOD - nic się nie zmieniło.
    Dalej robiłem testy i udało mi się sprowokować tą sytuację. Robię to tak:
    Wysyłam dane do komputera, odpowiadam.
    Hibernuje komputer.
    Wysyłam dane do komputera (bez odpowiedzi wiadomo)
    Włączam komputer.
    Wysyłam dane do komputera - przychodzą poprawnie.
    Odpowiadam do urządzenia ale nic się nie dzieje, toggle wskazuje że dane się pojawiają.
    Czyli co wina mojego kodu pewnie.
    hotdog - pisałeś że mam coś źle zrobionego w obsłudze przerwań ?
  • #29
    hotdog
    Level 26  
    No to wiesz na pewno że nie blokujesz przerwań i że masz gdzieś błąd w kodzie obsługi przerwania. Cieżko mi tutaj wróżyć.
         if(s == 13)
          {
             SETBIT(command, COMMAND_STATUS_WYKONAC);
          }
          else
          {
             if((command_in + 1) < 20)
             {
                buffer_comand[command_in] = s;
                command_in++;
             }
             else
             {
                SETBIT(command, COMMAND_STATUS_WYKONAC);
             }
          } 

    Zwróć uwagę że chyba nie zerujesz zmiennej command_in w tylu miejscach ilu powinieneś. Chyba że robisz to w programie głównym.
  • #30
    ja_fryta
    Level 19  
    Chyba udało mi się rozwiązać problem (chyba :P).
    Informacje wysyłane zaczynają się u mnie od znaku $ i nigdy nie są dłuższe niż 13 znaków.
    W przerwaniu miałem obsługę czytywania każdego znaku z osobna i zapisywania kolejno do tablicy char[13]. Gdy tablica się zapełniła ustawiane były informujące obsługę żeby wykonała polecenie. Właśnie w tym miejscu był problem zdarzało się że na uart pojawiały się jakieś "krzaki" (nie często ale jednak) i taki krzak sobie wskakiwał jako pierwszy element do tablicy a $ dopiero dalej i gdy tablica była pełna i następowała analiza, to nie pasowało do żadnej komendy, aplikacja zapętlała się. Dalej 13 znak z pierwszego polecenia trafiał jako pierwszy znak do drugiego i następowało błędne koło. W tej chwili dodałem sprawdzanie czy pierwszy znak to $ jeżeli tak wskaźnik ustawia się na element 0.
    Mam nadzieje że to pomogło. Poczekam parę dni i jak problem nie będzie występował to napiszę.
    Jak narazie to wielkie podziękowania za zaangażowanie z twojej strony hotdog i za pomysł z toggle.