> To oczywiście oczywista oczywistość. Z tym że to już wymaga chwili
> zastanowienia, choćby nad wydzieleniem części tylko do odczytu, którą
> pakuje się na cramfs (skompresowane i szybkie dość). Jeśli chodzi
> o zabawy, to podane wskazówki są wystarczające.
Wracając do wątku.
Rozpocząłem dyskusję (już ze 2 tygodnie) w Microchip Support.
Jedyną informację, jaką dostałem, to że mam spróbować połaczyć PGEC1 z PGEC2
i PGED1 z PGED2.
Jednak jest to niepotwierdzone, a ja jednak wylutowałem i wlutowałem (3 raz)
chip i teraz uważam, aby configuration bits ustawiać dokładnie tak jak ma
być.
Wydaje mi sie, że jest tam jakiś bag pozwalający zablokować chip w taki
sposób,
że procek nie daje objawów komunikacji z powodu braku taktowania.
S.

do góry

Użytkownik Jarosław Sokołowski napisał:
> PaN AlexY napisał:
[..]
>> Takich zabaw nie robiłem, ale katalog /var/log linuxa zabił kartę
>> pamięci w miesiąc.
>
> Po pierwsze, logować tylko to, co niezbędne. Po drugie, partycję zamontować
> z opcją "noatime" -- rzadko jest potrzebne zapisywanie informacji, kiedy
> każdy plik był czytany. Po trzecie -- montować z parametrem "commit" o dość
> dużej wartości. Na przykład commit=300 spowoduje, że bufory będą się
> synchronizowały z tym flashem co 5 minut, a nie co 5 sekund. Przy takim
> potraktowaniu karta wytrzymuje wiele lat.

Ależ prawie wszystko to było wykonane (z wyjątkiem commit'a bo nie
znalazłem opisu jak się go modyfikuje) a w miejscu /var/log miał być
symlink do dysku twardego o którym zapomniałem. To była sytuacja
awaryjna prowizorycznie naprawiona (a skoro działa to po co ruszać) przy
użyciu 2-ch czytników z kartami jako /usr i /var. Nie bawiłem się z
innymi systemami plików bo to debian a nie chciało mi się jaja kompilować.

--
AlexY
http://nadzieja.pl/inne/spam.html
http://www.pg.gda.pl/~agatek/netq.html

do góry

PaN AlexY napisał:

>> Po pierwsze, logować tylko to, co niezbędne. Po drugie, partycję
>> zamontować z opcją "noatime" -- rzadko jest potrzebne zapisywanie
>> informacji, kiedy każdy plik był czytany. Po trzecie -- montować
>> z parametrem "commit" o dość dużej wartości. Na przykład commit=300
>> spowoduje, że bufory będą się synchronizowały z tym flashem co 5 minut,
>> a nie co 5 sekund. Przy takim potraktowaniu karta wytrzymuje wiele lat.
>
> Ależ prawie wszystko to było wykonane (z wyjątkiem commit'a bo nie
> znalazłem opisu jak się go modyfikuje) a w miejscu /var/log miał być
> symlink do dysku twardego o którym zapomniałem. To była sytuacja
> awaryjna prowizorycznie naprawiona (a skoro działa to po co ruszać)
> przy użyciu 2-ch czytników z kartami jako /usr i /var. Nie bawiłem
> się z innymi systemami plików bo to debian a nie chciało mi się jaja
> kompilować.

Ten commit, to akurat kluczowy dla całej sprawy. Przy podanym ustawieniu
może zwiększyć żywotność karty 60 razy, a pozostałe rzeczy są w takiej
sytuacji głównie dla porządku. Ale i tak coś mi się widzi, że ta karta
musiała być jakaś delikatna. Mnie się nigdy żadnej wykończyć nie udało,
ale może słabo się starałem. Właściwie to nawet nie wiem w jaki sposób
one zdychają. Nagły szlag je trafia, czy agonia jest długa? Od razu cała
jest do bani, czy zawodzi tylko część, na przykład jedna partycja?

--
Jarek

do góry

On Thu, 1 Aug 2013 14:58:51 +0200, Sylwester Łazar<i...@a...pl>
wrote:
> Jedyną informację, jaką dostałem, to że mam spróbować połaczyć
PGEC1 z PGEC2
> i PGED1 z PGED2.

A tak formalnie zapytam, czy na pewno podlaczyles prawidłowo
wszystkie piny wymagane do poprawnego programowania wg. opisu w
dokumentacji (szczególnie avdd, avss itp.)?

--
Marek

do góry

> A tak formalnie zapytam, czy na pewno podlaczyles prawidłowo
> wszystkie piny wymagane do poprawnego programowania wg. opisu w
> dokumentacji (szczególnie avdd, avss itp.)?
Wydaje mi się, że tak. Wszystko zgodnie z karta katalogową.
Projekt na tym etapie już ukończyłem i wszystko ładnie działa.
Problem następuje po błędnym zaprogramowaniu słów konfiguracyjnych.
Wtedy koniec. Komunikat:
RIErr0035: Failed to get Device ID
Poniżej korespondencja z Microchipem. Pierwsza odpowiedź:

***** AUTOMATED MESSAGE - DO NOT RESPOND *****
Hello Sylwester Lazar,
Microchip Engineering Support has added comments to support Ticket 254885.
Comments:
HI Sylwester
Please upload schematics and the configuration bits that you programmed
wrong.
Best regards,
Horia


Problem Description:
Hello!
I had twice such a problem:
When I was try to implement asm example with core Timer, the chip start to
be" not answering" anymore.
That is what I have received in MPLAB 8.91:
MPLAB REAL ICE detected
Connecting to MPLAB REAL ICE...
Firmware Suite Version...... 01.28.74
Firmware type......................PIC32MX
MPLAB REAL ICE Connected.
Target Detected
RIErr0035: Failed to get Device ID
It happened probably after programing with not proper configuration bits
set.
That is second time, when I need to replace chip.
How to program it again without desoldering chip?
Best Regards,
Sylwester

do góry

Użytkownik Jarosław Sokołowski napisał:
[..]
> ale może słabo się starałem. Właściwie to nawet nie wiem w jaki sposób
> one zdychają. Nagły szlag je trafia, czy agonia jest długa? Od razu cała
> jest do bani, czy zawodzi tylko część, na przykład jedna partycja?

Z commit'em wierzę, chciałem zmienić ale nie znalazłem jak. Co do
zdechnięcia to nagle karta przestała istnieć, jest nieczytelna,
nierozpoznawalna i ogólnie martwa, jako że to był domowy serwer nie
ruszany czasem tygodniami to nie wiem czy były jakieś oznaki umierania.

--
AlexY
http://nadzieja.pl/inne/spam.html
http://www.pg.gda.pl/~agatek/netq.html

do góry

PaN AlexY napisał:

>> ale może słabo się starałem. Właściwie to nawet nie wiem w jaki sposób
>> one zdychają. Nagły szlag je trafia, czy agonia jest długa? Od razu cała
>> jest do bani, czy zawodzi tylko część, na przykład jedna partycja?
>
> Z commit'em wierzę, chciałem zmienić ale nie znalazłem jak. Co do
> zdechnięcia to nagle karta przestała istnieć, jest nieczytelna,
> nierozpoznawalna i ogólnie martwa, jako że to był domowy serwer nie
> ruszany czasem tygodniami to nie wiem czy były jakieś oznaki umierania.

Skoro "nie ruszany czasem tygodniami", to pewnie też będzie trudno
zweryfikować, czy "katalog /var/log linuxa zabił kartę pamięci w miesiąc".

--
Jarek

do góry

Użytkownik Jarosław Sokołowski napisał:
> PaN AlexY napisał:
[..]
> Skoro "nie ruszany czasem tygodniami", to pewnie też będzie trudno
> zweryfikować, czy "katalog /var/log linuxa zabił kartę pamięci w miesiąc".

Nic innego nie mogło, ewentualnie /var/run, dochodzenia nie będzie :)
Karta od /usr żyje nadal.

--
AlexY
http://nadzieja.pl/inne/spam.html
http://www.pg.gda.pl/~agatek/netq.html

do góry

PaN AlexY napisał:

>> Skoro "nie ruszany czasem tygodniami", to pewnie też będzie trudno
>> zweryfikować, czy "katalog /var/log linuxa zabił kartę pamięci w miesiąc".
>
> Nic innego nie mogło, ewentualnie /var/run, dochodzenia nie będzie :)

Ale to, że "w miesiąc", to skądeś wiadomo?

> Karta od /usr żyje nadal.

To tam więcej niż jedna była? Jak serwer ma być do serwowania, a nie
do logowania, to mu można w ogóle sysloga wyłączyć i podlinkować to
co trzeba do /dev/null.

--
Jarek

do góry

Użytkownik Jarosław Sokołowski napisał:
> PaN AlexY napisał:
>
>>> Skoro "nie ruszany czasem tygodniami", to pewnie też będzie trudno
>>> zweryfikować, czy "katalog /var/log linuxa zabił kartę pamięci w miesiąc".
>>
>> Nic innego nie mogło, ewentualnie /var/run, dochodzenia nie będzie :)
>
> Ale to, że "w miesiąc", to skądeś wiadomo?

Przestał być widoczny w sieci, WWW jest w /var

>> Karta od /usr żyje nadal.
>
> To tam więcej niż jedna była? Jak serwer ma być do serwowania, a nie
> do logowania, to mu można w ogóle sysloga wyłączyć i podlinkować to
> co trzeba do /dev/null.

Podałem wcześniej, były 2, na jedną było za dużo danych. Miał być
pełnoprawnym systemem z normalną funkcjonalnością, zwykła skleroza że
zapomniałem o symlinku na logi. Już po znalazłem że katalog gdzie miały
one być był pusty.

--
AlexY
http://nadzieja.pl/inne/spam.html
http://www.pg.gda.pl/~agatek/netq.html

do góry