W dniu 2014-07-10 15:52, Atlantis pisze:
> W dniu 2014-07-09 20:50, Adam Górski pisze:
>
>> 1) Co to znaczy : "się zawiesił". Nie istnieje takie pojęcie.
>> Zawiesić to się może jak zegar zniknie.
>> Wisi gdzieś czekając na coś. Na co ?
>
> Tak jak mówiłem - po zresetowaniu ATmegi przez watchdoga nie mogę
> ponownie nawiązać połączenia z układem, a jedna z diod na gniazdku RJ45
> (ta, która normalnie świeci cały czas) dość szybko miga. Pomaga dopiero
> ponowne uruchomienie układu przez chwilowe odcięcie zasilania.
>
>
>> 2)Gdzieś widziałem w dokumentacji minimum 2us.
>
> A jest jakieś maksimum? Bo próbowałem resetu sprzętowego, ustawiając pin
> na stan nisku na kilkadziesiąt-kilkaset ms. Układ w ogóle nie łączył się
> z siecią - to znaczy nawet nie zaświeciła się żadna dioda.
>
Maksimum nie widziałem.

Proponuje wykonać odczyt wszystkich rejestrów wew ENC i porównać. Co
zawierają po power-up a co po resecie.

Dużo masz tego softu ?

Adam

---
Ta wiadomość e-mail jest wolna od wirusów i złośliwego oprogramowania, ponieważ
ochrona avast! Antivirus jest aktywna.
http://www.avast.com

do góry

On Thu, 10 Jul 2014 15:52:48 +0200, Atlantis <m...@w...pl>
wrote:
> Tak jak mówiłem - po zresetowaniu ATmegi przez watchdoga nie mogę
> ponownie nawiązać połączenia z układem, a jedna z diod na gniazdku
RJ45
> (ta, która normalnie świeci cały czas) dość szybko miga. Pomaga
dopiero

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.

--
Marek

do góry

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

> To wygląda jakby po reset wdg nie były prawidłowo skonfigurowane
> piny/porty do komunikacji (hardware)

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?

> prawidlowo reinicjowany. Zrobiłbym test jak się zachowa na reset na
> pinie MCLR mcu, przypuszczam że będzie ten sam efekt.

Faktycznie, spróbuję po powrocie do domu.

do góry

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

> jak się zachowa na reset na pinie MCLR mcu, przypuszczam że będzie ten
> sam efekt.

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...

do góry

On Fri, 11 Jul 2014 23:27:46 +0200, Atlantis <m...@w...pl>
wrote:
> Dziwna sprawa. Po resecie przez zwarcie pinu układ wstaje normalnie.
> Tylko watchdog powoduje ten dziwny efekt. Generalnie mam wrażenie,
że to

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

--
Marek

do góry

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

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

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.

do góry

On Sat, 12 Jul 2014 00:53:49 +0200, Atlantis <m...@w...pl>
wrote:
> 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...

--
Marek

do góry

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

> 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...

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. ;)

do góry

On Sat, 12 Jul 2014 09:07:33 +0200, Atlantis <m...@w...pl>
wrote:
> Programowy reset polega na ustawieni krótkiego cyklu watchdoga (w
moim
> przypadku 15 ms) i uruchomieniu nieskończonej pętli. W efekcie wdt

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.

--
Marek

do góry

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

> 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

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.

do góry