microgeek.eu

Witam.

Po ostatnich bojach z obsługą usbasp z poziomu Arduino IDE 1.8.5 oraz wypalaniem bootloadera miałem cichą nadzieję, że to już koniec problemów, ale niestety pojawił się problem nagłych i nieoczekiwanych resetów procesora. Nie, to nie wina programu ani bootloadera - bootloader nawet wywaliłem z procesora, a sam procesor poddałem przywróceniu do ustawień fabrycznych. Wiem, że FT232 wymusza reset procesora, by odezwał się bootloader i umożliwił załadowanie programu przez UART. Cały układ wygląda tak:

Arduino_M8_FT232_schematic.JPG

To jest oczywiście jakieś inne Arduino i nawet procesor jest inny (ATmega8), ale jest obecny FT232RL oraz układ "auto reset". Zasadniczo całość załatwia kondensator C13. Niestety nie udało mi się znaleźć na mojej płytce rezystora R2 i, prawdę mówiąc, nawet nie mam pojęcia, po co on tam ma być.

No i teraz główne pytanie: Czy brak rezystora R2 może powodować losowo występujące resety procesora?
Po co jest ten rezystor R2?
A może wina leży po stronie sterownika FTDI w Windows 10?
A może FT232RL należy poddać jakiejś konfiguracji?

a czy masz wyprowadzoną zworkę "reset_en"? rozlutuj/rozetnij ją i zobacz jak układ się zachowuje - jesli tam jest problem to od biedy będziesz miał dostęp tylko do programowania przez zewnętrzny programator

Jest jeszcze taka ewentualność, że w AVR'ach nieobsługiwane przerwania są traktowane identycznie jak reset (jako wektor przerwania o numerze 0). Czy dajesz gwarancję, że nie generują się nieoczekiwane przerwania?

dambo pisze:a czy masz wyprowadzoną zworkę "reset_en"?

Tak, mam i jest obecnie zwarta, dlatego zdarzają się resety. przeprowadziłem długotrwałą obserwację i wynika z niej, że to FT232 (chyba na rozkaz sterownika w Windows) co jakiś czas odczynia jakieś czary, w wyniku których pojawia się krótki impuls na pinie 2 układu FT232, czyli na DTR. Rozepnę tę zworkę, by mieć 1000% pewności.

gaweł pisze:Czy dajesz gwarancję, że nie generują się nieoczekiwane przerwania?

Tak, gwarantuję, że to nie jest wina softu. Układ ATmega2560 został wczyszczony, ustawiony na nowo i zaprogramowany programem napisanym w surowym C i oczywiście również się resetuje, bo i w tym przypadku docierają impulsy resetujące z pinu DTR...

Dalsze badania przyniosły następujące wnioski:
Procesor resetuje się tylko wtedy, gdy zasilany jest przez USB. Napięcie na płytce wynosi wtedy około 4.88V, a przy podłączonym TFT napięcie spada do koło 4.75V. Tak, sprawdziłem ustawienia BOD. Tak, jest nieaktywny.
Procesor nie resetuje się, gdy, mimo zasilania z USB, uruchomię połączenie przez UART z tą płytką. A zatem... Arduino ma zasilanie z USB, w komputerze mam uruchomiony program Terminal by Br@y, a w nim wybrany port COM5 (przejściówka FTDI znajdująca się na Arduino), prędkość 57600 i kliknięty przycisk "connect". Test trwa już około 30 minut i nie nastąpił nawet jeden reset. Sam już nie wiem, co o tym wszystkim myśleć.

Może jakość gniazda/przewodu? Ile to już razy kombinowałem z czymś na różne sposoby, aż w końcu przywróciłem ustawienia początkowe i zmieniłem przewód zasilający/połączeniowy

dambo pisze:Może jakość gniazda/przewodu?

Przewód wymieniłem na inny (wielokrotnie sprawdzony), a gniazdo przelutowałem i umyłem. To jest gniazdo USB B, więc trzeba naprawdę dużo złej woli, by je zepsuć. To wszystko oczywiście nie pomogło, więc na koniec spróbowałem zaktualizować sterownik dla FT232RL. Windows pobrał jakieś sterowniki ze swoich zasobów online, ale to nie poprawiło sytuacji.

Edit 06.02.2018 --------------------------------

Wziąłem "na warsztat" pozostałe FT232RL i wszystkie zachowują się podobnie. Od czasu do czasu migają diodą led, zmieniają poziom logiczny na pinie DTR... Czasami jakby spały i wtedy nie da się ich odczytać programem FT_PROG... A na dodatek pod linuxem wszystko działa idealnie. Wszystkie przejściówki pracują, przejściówka na arduino zawsze i o każdej porze się odzywa, zawsze potrafi zaprogramować procesor i nie resetuje go bez potrzeby.

Przynajmniej wiem, że nie mam co szukać błędów w płytce arduino, bo problem tkwi gdzieś w obsłudze FT232 w Windows 10. Szczerze mówiąc nie mam pojęcia, do czego mógłbym się przyczepić (w Windows).

Uwaga, uwaga! Przyczyna wariowania układów FT232 została znaleziona i usunięta!

Przyczyną okazało się oprogramowanie zarządzające UPS'em, a jego nazwa to "View Power". Kiedyś zainstalowałem ów soft, by stwierdzić, co w trawie piszczy, ale ostatecznie korzystam z innego UPS'a. Soft został...i gdzieś tam pewnie odpytywał porty COM. Oprogramowanie zostało odinstalowane i natychmiast resety zniknęły.

Pozdrawiam!

Brawo!

Teraz wpadłem na to - że przy takim podobnym czymś CHYBA można wiresharkiem sprawdzić co się dzieje na USB - jaki program dobiera sie do jakiego urzadzenia. Wiem, ze zawsze przy instalacji Wireshark pyta czy instalowac takie narzędzie, ale nigdy nie potrzebowałem i go nie wgrywałem

Brawo Ty.
Czyli sugestie, że to jakiś soft były trafione, a naprowadzał na to fakt, że jak pisałeś połączenie się konsolą powodowało znikanie problemu.
Jak jeden program zajmie port COM to reszta nie ma do niego dostępu, więc i nie może restartować.
Najważniejsze, że Twoja upartość się opłaciła .

Grzegorz... pisze:Najważniejsze, że Twoja upartość się opłaciła

Ot, miałem nieodparte wrażenie, że wcześniej nie miałem takich problemów z ftdi

Pewnie masz rację, ale sprawa tyczyła się pojedynczego FTDI podłączonego do komputera

CP2102 też mangluje liniami DTR/RTS przy inicjowaniu portu więc domniemywam, że w tym przypadku to nie wina samego FTDI

xor pisze:CP2102 też mangluje liniami DTR/RTS przy inicjowaniu portu

Ok, ale problem występował już po enumeracji i uruchomieniu portu w systemie.

Po enumeracji ale nie po uruchomieniu. Uruchomienie nastąpiło wraz z kliknięciem "connect" w Bray Terminal.

Po enumeracji urządzeń na USB. Jeśli wszystko poszło zgodnie z planem, uruchamiany jest port COM, a nawiązanie połączenia przez ten port jest inną kwestią. Tak więc uruchomienie nie nastąpiło wraz z kliknięciem "connect", a w momencie prawidłowej konfiguracji urządzenia USB w systemie.

Etam, enumeracja to tylko zarejestrowanie w systemie nowego urządzenia, które nic nie robi i się nudzi dopóki jakiś proces nie wykona "otwarcia" urządzenia (czyli jego "uruchomienia"). Tak to widzę.
Tak czy inaczej, posiadana przeze mnie przejściówka na CP2102 też powoduje resety w momencie otwarcia (uruchomienia ) portu ttyUSB, więc to nie jest jakaś tam przypadłość FTDI jedynie. I tylko to właściwie chciałem powiedzieć.

Oczywiście zgadzam się co do faktu pojawiania się impulsu reset podczas podłączania przejściówki do USB, ale nie mogę się zgodzić w kwestii uruchamiania. System, po enumeracji, uruchamia obsługę tego urządzenia,, o ile użytkownik nie zażyczy sobie inaczej (menedżer urządzeń/USB Serial Converter/ właściwości/sterownik/ wyłącz urządzenie). Od tego momentu proces może otworzyć port lub nawiązać połączenie (od open lub connect), ale nie uruchomić, bo port COM już jest uruchomiony. Być może w GNU/Linux jest inne nazewnictwo, ale cały problem dotyczył pracy FTDI w systemie Windows.

Oczywiście można stwierdzić, że uruchomiony oznacza aktywny, a aktywny oznacza przesyłający jakieś dane... To tylko kwestia interpretacji

Jak zwał tak zwał, czy ktoś to nazwie uruchomieniem czy nie to powód jak pisałeś jest dość prozaiczny, bo nie zajęty niczym port COM jest dostępny dla każdego uruchomionego programu i jeśli zechce się go o coś odpytać to może wywołać podobne efekty. Tu wracając do tematu poruszanego przez Rezę to być może właśnie dlatego AD2 tak "rządzi" FTDI aby nikt inny nie mieszał po podłączeniu tego pudełka.