Dziwne zachowanie ENC28J60 po softresecie ATmegi

To wygląda jakby po reset wdg nie były prawidłowo skonfigurowane piny/porty do komunikacji (hardware), czyżby reset po wdg czyms się różni od resetu poweron? Na pewno przebiega szybciej, być może za szybko przez co emcj nie jest prawidlowo reinicjowany. Zrobiłbym test jak się zachowa na reset na pinie MCLR mcu, przypuszczam że będzie ten sam efekt.

W dniu 2014-07-10 18:03, Marek pisze:

To trochę dziwne, bo przecież kod jest ten sam. O ile dobrze pamiętam na samym początku idzie wstępna konfiguracja portów - wszystkie są ustawione na wejście podciągnięte do VCC, żeby później uniknąć problemów, ewentualnie w razie potrzeby jest to później zmieniane w funkcjach inicjujących pracę poszczególnych peryferiów. Potem idzie inicjacja i konfiguracja jednego timera (ENC28J60 i Stos z niego nie korzystają, obsługuje on zdarzenia w pętli głównej) i licznika zliczającego zewnętrzne impulsy. Dalej program sprawdza stan konfiguracji zapisanej w pamięci EEPROM. Jeśli pamięć jest pusta (np. po porgramowaniu układu) przywraca domyślną wartość z flasha. To samo dzieje się po wykryciu stanu niskiego na jednym z pinów (zworka przywracania "fabrycznej" konfiguracji). Na tym etapie program ładuje do RAM-u strukturę z danymi konfiguracyjnymi (jest wśród nich m.in. MAC i numery IP: własny i bramy).

Dopiero teraz następuje inicjacja pracy ENC28J60, konfiguracja pracy diodek, ustawienie odpowiedniej częstotliwości na CLKOUT (12.5 MHz) i odpalenie stosu.

Po włączeniu urządzenia do sieci wszystko przebiega normalnie, za to po resecie przez watchdog układ wariuje wg schematu opisanego wcześniej.

BTW czy fakt pracy ATmegi na taktowaniu z CLKOUT ENC28J60 może mieć jakiś związek w tym stanem rzeczy?

Faktycznie, spróbuję po powrocie do domu.

W dniu 2014-07-10 18:03, Marek pisze:

Dziwna sprawa. Po resecie przez zwarcie pinu układ wstaje normalnie. Tylko watchdog powoduje ten dziwny efekt. Generalnie mam wrażenie, że to miganie wygląda tak, jakby MCU wpadał w jakąś pętlę resetu. Bo dioda połączenia faktycznie przygada podczas resetowania...

Ja bym jeszcze zrobił test z innym źródłem zegara mcu (nie encj).

W dniu 2014-07-12 00:43, Marek pisze:

Ok, już znalazłem przyczynę. Kto by pomyślał, że w ATmedze:

1) Watchdog jest ciągle aktywny po resecie. 2) Nie można go tak po prostu wyłączyć, najpierw trzeba zresetować bit WDRF w rejestrze MCUCSR.

Nie rozumiem, jakie to ma znaczenie, że jest aktywny? Dla prawidłowo działającego softu i sprzetu będzie periodycznie kasowany, jeśli będzie znowu (po resecie) aktywny...

W dniu 2014-07-12 08:35, Marek pisze:

WDT jest periodycznie kasowany w pętli głównej. Opisywany problem występował zanim jeszcze program dochodził do tego momentu.

Programowy reset polega na ustawieni krótkiego cyklu watchdoga (w moim przypadku 15 ms) i uruchomieniu nieskończonej pętli. W efekcie wdt zresetuje MCU.

Zakładałem, że po takiej procedurze układ startuje od nowa, czyli również z wyłączonym watchdogiem. Myliłem się.

Potem pomyślałem, że może jednak watchdog jest aktywny i to on (zgodnie z ostatnim ustawieniem) resetuje mi układ już na starcie, po 15 ms. Okazało się jednak, że wdt_disabkle() na samym początku funkcji main() nie pomaga.

Potem spróbowałem ustawić dłuższy cykl wdt w procedurze soft resetu -

4s. Sądziłem, że wtedy przynajmniej ENC28J60 zdąży się zainicjować i coś zobaczę. Ale nie - efekt był taki sam. Wtedy pomyślałem, że być może po restarcie licznik watchdoga nie znajduje się w stanie 0, spróbowałem więc konstrukcji:

wdt_reset(); wdt_disable();

Też nie pomogło. W akcie desperacji zrobiłem coś takiego:

wdt_reset(); MCUCSR &= ~(1 << WDRF); wdt_disable();

I voila! Zadziałało. ;)

No na to bym nie wpadł, żeby ustawiać czas wtd na 15ms w prototypach,

5s to rozumiem ale 15ms to proszenie się o problemy. Całkiem niedawno miałem przypadek gdzie 5s było za mało, fopen na pliku 2kB i fwrite 100 bajtów na jego koniec (pendrive usb z mocno sfragmentowanym fatem) bibliotece vfat, której używam, zajmowało 8s.

W dniu 2014-07-12 09:57, Marek pisze:

Ciągle się nie rozumiemy. Tak krótki czas stosuję TYLKO w procedurze soft resetu, żeby użytkownik nie musiał czekać na jego wykonanie.

void soft_reset (void) { wdt_enable(15MS); while(1); }

Normalnie stosuję długi czas, bodajże 4 sekundy, z licznikiem zerowanym co sekundę w pętli głównej.

Zresztą jak już mówiłem - próbowałem też soft resetu z długim watchdogiem i nie robiło to żadnej różnicy. Układ i tak wpadał w pętlę resetu po pierwszym wykonaniu tej funkcji. Pomogło dopiero zerowanie jednej flagi i wyłączanie wdt na samym początku programu.

No nie rozumiem zupelnie, o jakim czekaniu na reset mówisz (reset to reset, instrukcja natychmistowa) i po co w ogóle taka funkcja? Czyżby atmega nie ma instrukcji "reset", żeby ją użyć jak jest potrzeba resetu i trzeba takie cuda pisać?

Tego też nie rozumiem, po co układ ma wpadać w funkcję resetu? Nie znam się kompletnie na atmegach i nasze nieporozumienie wynika chyba z tego, że rozwiązujesz problemy nieistniejące w innych systemach (czyt. mcu) ;)

W dniu 2014-07-12 11:01, Marek pisze:

No właśnie chyba nie ma. Nawet gdzieś na stronach Atmela widziałem tekst, w którym opisywano właśnie taki sposób na programowy reset MCU.

Najwyraźniej. Dziwne jest to, że po resecie przez watchdoga, ten ostatni ciągle pracuje. W dodatku nie da się go tak po prostu wyłączyć, tylko trzeba najpierw wyzerować flagę. Całkowicie nieintuicyjne rozwiązanie...

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

Pierwszy wynik z Google, chyba wyczerpuje temat :)

W dniu 2014-07-12 11:01, Marek pisze:

Tak swoją drogą fakt, to trochę dziwne. Jednak w tej chwili przyglądam się bliżej PIC-om i one też mają pewne słabe strony w porównaniu do AVR-ów. Najbardziej zaskoczył mnie fakt, że nie wszystkie piny mogą oddawać jednakowy prąd, a także nie wszystkie dysponują wewnątrznym pull-upem. W ATmegach nie muszę się tym przejmować, co nieco ułatwia projektowanie płytki.

Z drugiej strony chciałbym, żeby ATmel produkował ośmiobitowe MCU z takim wachlarzem różnych interfejsów (CAN, Ethernet).

Tylko nie skupiaj się czasem na picach 16f czy mniej (minumum 18f). W picach 16f i mniej najczęściej nie ma możliwości selektywnego pullapa (wybrany pin), albo cały port (B) albo wcale.

W dniu 2014-07-14 13:02, Marek pisze:

To oczywiste. Nie mam zresztą takiej potrzeby, bo do prostszych projektów mogę wykorzystać zgromadzony "zapas" AVR-ów. PIC-om przyglądam się z uwagi na kilka modeli, które nie mają swoich bezpośrednich odpowiedników wśród produktów Atmela (np. PIC18F67J60 z wbudowanym modułem Ethernet, ewentualnie MCU w SO28 z większą ilością peryferiów).

Generalnie wychodzi na to, że wcale nie tak trudno połapać się w jednej rodzinie, gdy poznało się jakąś inną. Filozofia obsługi podobna, pomimo pewnych różnic, które są do opanowania. Pewnie jeszcze po drodze przyjrzę się rodzinie XMega. Dzięki narzędziom dostarczonym przez Atmela nie trzeba bawić się rejestrami na niskim poziomie, a mają kilka fajnych cech (np. sprzętową obsługę AES).