Pszemol <P...@P...com> wrote:
> Teraz na ten przykład krokuję program (breakpoint na wejsciu do funkcji
> kasowania sektora) i widzę, że tak traktowany sprzęt zachowuje się ładniej
> - zamiast wywalić się na kasowaniu pierwszego sektora (0x8000 0000)
> przeszedł ladnie do kasowania
> 0x800C 0000, 0x800E 0000, 0x8010 0000 zapisujac je po kolei bez zgłaszania
> błędów i po skasowaniu 0x8012 0000 wykorbił się w czasie zapisu nowych
> danych:
>
> Górna kostka, ta obsługująca bity D16..D31, zgłosiła błąd zapisu: ustawiony
> bit D5 kostki (u mnie cpu widzi go jako D21) przy przestawianym wciąż bicie
> D6 (u mnie D22).
>
> I co teraz? Zaczynam kurna podejrzewać nasz hardware... Może coś jest nie
> tak z jakością 3V3... Czas przynieść oscylka :-)

Kodensatorek osprzegajacy był na innej nodse podpiętej do 3v3 ale po
podpieciu dodatkowego 220nF do nozki 43 nic sie nie zmieniło na plus...
Dalej sie proces wykorbia w czasie kasowania lub programowania...

do góry

On 2017-02-08 17:26, Pszemol wrote:
> Adam Górski <gorskiamalpawpkropkapeel_@xx> wrote:
>> A nie trzeba tam gdzies czekać na bity ze status registru ?
>>
>
> Z tego pytania wnioskuję, że na funkcje zapisu i kasowania jakie tu podałem
> nawet nie spojrzałeś :-)))
>

Spojrzałem. Nie podejmuje się analizowania czegoś takiego jak while( A,
B,C ). Nigdzie nie widziałem jeszcze takiej konstrukcji.

Czy możesz podpowiedzieć jaki jest oczekiwany rezultat takiej pętli ?
Czy w takim wypadku oczekujesz wszystkich warunków niezerowych czy
wystarczy jeden ? Inaczej mówiąc to jest bardziej jak && czy ||. A może
tylko jedno jest warunkiem ?

Widziałeś gdzieś definicję takiej pętli ? Wybacz moje niedouczenie.

Z drugiej strony , na ilu szt. hardwaru masz takie zachowanie ?
Może normalnie masz zwalony hardware.



Adam

do góry

On 2017-02-09 12:58, Adam Górski wrote:
> Czy możesz podpowiedzieć jaki jest oczekiwany rezultat takiej pętli ?
> Czy w takim wypadku oczekujesz wszystkich warunków niezerowych czy
> wystarczy jeden ? Inaczej mówiąc to jest bardziej jak && czy ||. A może
> tylko jedno jest warunkiem ?

Ostatnie jest warunkiem. Reszta ma się po prostu wykonać przed
wyliczeniem warunku.

Piotrek

do góry

On 2017-02-09 14:17, Piotrek wrote:
> On 2017-02-09 12:58, Adam Górski wrote:
>> Czy możesz podpowiedzieć jaki jest oczekiwany rezultat takiej pętli ?
>> Czy w takim wypadku oczekujesz wszystkich warunków niezerowych czy
>> wystarczy jeden ? Inaczej mówiąc to jest bardziej jak && czy ||. A może
>> tylko jedno jest warunkiem ?
>
> Ostatnie jest warunkiem. Reszta ma się po prostu wykonać przed
> wyliczeniem warunku.
>
> Piotrek
>

Dzięki. We wszystkich definicjach jakie widziałem zawsze jest while(
condition ). Masz może namiar na opis standardu dopuszczającego takie
użycie ?

Adam Górski

do góry

On 2017-02-09 14:32, Adam Górski wrote:
> Dzięki. We wszystkich definicjach jakie widziałem zawsze jest while(
> condition ). Masz może namiar na opis standardu dopuszczającego takie
> użycie ?

No i właśnie to condition jest grupą wyrażeń połączonych *operatorem* ,

Było od zawsze ("The C programming Language" A.7.18). Chociaż
rzeczywiście widziałem to użyte w kodzie może z pięć razy.

Piotrek

do góry

W dniu 2017-02-08 o 20:31, Pszemol pisze:
>
> Zerknij proszę jeszcze raz na deklarację wskaźnika pStatus oraz zmiennych
> Status1 i Status2.
> To są obiekty 32-bitowe a więc obie kostki pamięci odpowiedzialne są za ich
> zapis.
>

while(Status1 = *pStatus, Status2 = *pStatus, (Status1 ^ Status2) & (1
<< 2))
Przepraszam że zawracam głowę, ale jaki jest sens robienia XOR na
zmiennych pobierających wartość z tego samego adresu?
Tam (praktycznie) zawsze będzie false, chyba że procesor akurat trafi na
zmianę statusu drugiej kostki między jednym a drugim odczytem *pStatus,
ale z takim szczęściem to lepiej kupony wypełniać niż babrać się w kodzie ;)

--
Pozdrawiam
Piotrek

do góry

Użytkownik "Pszemol" napisał w wiadomości grup
dyskusyjnych:o7f8jr$e99$...@d...me...
//check toggle bit2 indicating erase operation pending
while(Status1 = *pStatus, Status2 = *pStatus, (Status1 ^ Status2) &
(1 <<
2))

Tez mi sie ten kod nie podoba, ale patrze, patrze ... i bledu nie
widze :-)
Program sprawdzony z 1 koscia ?
Pierwsze co mi sie nie podoba ... czytam status1, pamiec konczy
czysczenie, do status2 czytam juz dane.
Ale nieszczescia nie bedzie ... jak bit niezgodny, to przeczytamy
jeszcze raz, a ewentualny blad bierzemy z bitow status1.
Jak zgodny, to jak rozumiem pamiec zakonczyla kasowanie poprawnie ?

{
if(Status1 & (1 << 5)) // check error bit on one chip
{
LEDFRed();
return 0;

A te bledy sie zgadzaja ? Co wtedy robisz ?
Bo tu mi jedna mozliwosc sie rysuje - pierwsza kostka zglasza blad,
robimy return ... a druga sie ciagle kasuje.
Jesli teraz zacznies jakies resety robic, to kto wie, jak to sie dla
drugiej skonczy.

}
}
while(Status1 = *pStatus, Status2 = *pStatus, (Status1 ^ Status2) &
(1 <<
(16+2)))

To mi sie nie podoba - bo najpierw sprawdzalismy pierwsza koste, a
druga lezala odlogiem.
Ale jesli w tym czasie druga sie skonczyla ... to program pojdzie
dalej, jak nie skonczyla, to poczeka,
jak zglasza blad ... dlugo to wachlowanie bitem wtedy trwa ? Czy nie
ma sytuacji takiej, ze druga kosc ma blad, a Ty ciagle w pierwszej
petli sprawdzasz pierwsza. Pierwsza sie skasuje, a drugiej juz sie
znudzi wachlowanie..

{
if(Status1 & (1 << (16+5))) // check error bit on second chip
{
LEDFRed();
return 0;
}
}


No i ... przerwania wylaczyles ? Bo jesli jakis odczyt sie zapląta
miedzy odczyt status1 i 2, to zakonczysz czekanie przed czasem

// Check the erase
if(*pSector != 0xffffffff)
{
LEDFRed();
return 0;

Moze sprawdzic caly blok, a nie tylko poczatek ?
Predkosciowo pamiec wyrabia ? moze trzeba troche opoznien dodac ?

}
else
return 1;
}

// returns 1 if success
int STFlashWrite32(unsigned int Address, unsigned char *pSource,
unsigned int Size)

A problem jest w kasowaniu czy w zapisie ?

{
int Timeout;
U32 Status1, Status2;
volatile U32 *pDest = (volatile U32 *)Address;
U32 *pData = (U32 *)pSource;

// EMCSC bit in System Controls and Status register is cleared in
Flash_Init().
// It controls how addresses are output on the EMC address pins.
// For 32 bit bus the address is shifted so A2 is on A0 pin.
U32 *pA1 = (U32 *)(EXTERNAL_FLASH_LOCATION + (0x555 << 2)); //555
16bit
mode
U32 *pA2 = (U32 *)(EXTERNAL_FLASH_LOCATION + (0x2AA << 2)); //2AA
16bit
mode

moze jakis volatile by sie przydal - bo jak kompilator wykryje, ze
stale pod jeden adres zapisuje to samo, to moze zoptymalizowac.

Cache jakiegos ten procesor nie ma ? Te zapisy wychodza do pamieci ?

J.

do góry

Piotr Dmochowski <i...@p...onet.pl> wrote:
> W dniu 2017-02-08 o 20:31, Pszemol pisze:
>>
>> Zerknij proszę jeszcze raz na deklarację wskaźnika pStatus oraz zmiennych
>> Status1 i Status2.
>> To są obiekty 32-bitowe a więc obie kostki pamięci odpowiedzialne są za ich
>> zapis.
>>
>
> while(Status1 = *pStatus, Status2 = *pStatus, (Status1 ^ Status2) & (1
> << 2))
> Przepraszam że zawracam głowę, ale jaki jest sens robienia XOR na
> zmiennych pobierających wartość z tego samego adresu?
> Tam (praktycznie) zawsze będzie false, chyba że procesor akurat trafi na
> zmianę statusu drugiej kostki między jednym a drugim odczytem *pStatus,
> ale z takim szczęściem to lepiej kupony wypełniać niż babrać się w kodzie ;)
>

Piotrze, świetne pytanie.
Bo to jest ciekawy fragment procesu kasowania pamieci flash i zapisu do
niej.

Taka pamięć ma wewnątrz sterownik ktory kontroluje te procesy niejako z
wewnątrz kostki. Obsługujesz go przez wspólną magistralę danych i adresów -
scalak pracuje w dwu trybach: odczyt danych (wtedy działa jak klasyczny
ROM) oraz kasowanie/zapis: wtedy uzyskujesz dostep do wewnetrznego
sterownika umówioną sekwencję bajtôw w roli "sezamie otwórz się!" I wtedy
możesz wydawać sterownikowi polecenia kasowania/zapisu konkretnych
lokalizacji pamięci... A sterownik informuje Cie o postepie operacji
kasowania i o błedach ustawiajac stan bitow szyny danych. Miedzy innymi
zmienia on stan bitu D6 gdy operacja jest wciaz w toku. Stad w kodzie dwa
kolejne odczyty i stad użycie sugestii "volatile" do kompilatora aby tych
dwu odczytów nie "zoptymalizowal" myslac ze są bez sensu, tak jak Ty
pomyślałes :-))

Nawiasem mówiąc zmiana testu bitu D2 na bit D6 w czasie kasowania pomogla -
nie mam juz błędów o ktorych pisałem wcześniej.
Muszę jeszcze raz się przyjrzeć tym flołczartom z dataszyta :-) i
przypomnieć sobie dlaczego pisząc ten kod uznałem że testowanie D6 będzie
dobre w czasie zapisu flash a powinienem testować D2 w czasie kasowania...

do góry

W dniu 2017-02-10 o 15:55, Pszemol pisze:
> Piotr Dmochowski <i...@p...onet.pl> wrote:
>> W dniu 2017-02-08 o 20:31, Pszemol pisze:
>>>
>>> Zerknij proszę jeszcze raz na deklarację wskaźnika pStatus oraz zmiennych
>>> Status1 i Status2.
>>> To są obiekty 32-bitowe a więc obie kostki pamięci odpowiedzialne są za ich
>>> zapis.
>>>
>>
>> while(Status1 = *pStatus, Status2 = *pStatus, (Status1 ^ Status2) & (1
>> << 2))
>> Przepraszam że zawracam głowę, ale jaki jest sens robienia XOR na
>> zmiennych pobierających wartość z tego samego adresu?
>> Tam (praktycznie) zawsze będzie false, chyba że procesor akurat trafi na
>> zmianę statusu drugiej kostki między jednym a drugim odczytem *pStatus,
>> ale z takim szczęściem to lepiej kupony wypełniać niż babrać się w kodzie ;)
>>
>
> Piotrze, świetne pytanie.
> Bo to jest ciekawy fragment procesu kasowania pamieci flash i zapisu do
> niej.
>
> Taka pamięć ma wewnątrz sterownik ktory kontroluje te procesy niejako z
> wewnątrz kostki. Obsługujesz go przez wspólną magistralę danych i adresów -
> scalak pracuje w dwu trybach: odczyt danych (wtedy działa jak klasyczny
> ROM) oraz kasowanie/zapis: wtedy uzyskujesz dostep do wewnetrznego
> sterownika umówioną sekwencję bajtôw w roli "sezamie otwórz się!" I wtedy
> możesz wydawać sterownikowi polecenia kasowania/zapisu konkretnych
> lokalizacji pamięci... A sterownik informuje Cie o postepie operacji
> kasowania i o błedach ustawiajac stan bitow szyny danych. Miedzy innymi
> zmienia on stan bitu D6 gdy operacja jest wciaz w toku. Stad w kodzie dwa
> kolejne odczyty i stad użycie sugestii "volatile" do kompilatora aby tych
> dwu odczytów nie "zoptymalizowal" myslac ze są bez sensu, tak jak Ty
> pomyślałes :-))
Widziałem deklarację z volatile, więc wiem że powinny być 2 odczyty.
Zastanawia mnie jaki jest sens odczytania danych z jednego adresu i
zrobienie na nich XORa. Jeżeli między jednym a drugim odczytem nie
będzie zmiany to wynik będzie zerowy i program nie wejdzie do pętli -
takie jest moje rozumowanie. Może w praktyce jakoś to działa, ale
zastanawiam się jaki jest margines błędu w takim rozwiązaniu.
Jak najbardziej rozumiem pobranie jednego statusu i sprawdzenie D6, bez
XOR to nie pójdzie?
Ja bym dał w pętli odczyt statusu i sprawdzenie D6. Wyjście z pętli
jeżeli D6 ma odpowiednią wartość lub liczba sprawdzeń przekroczyła np.
100 (i sygnalizacja błędu przekroczonego czasu trwania operacji).

Chyba że czegoś nie ogarniam i ten odczyt z pamięci ma jakieś dodatkowe
skutki i może spowodować zmianę odczytanej wartości, ale bez takiej
wiedzy nie do końca mi się to składa w całość.

Tak przy okazji pokazywania kodu - myślę że nawet po jednym zdaniu
komentarza przed kawałkiem kodu byłoby dobra zachętą do analizowania
przez grupowiczów, a i koledzy w pracy pewnie tez docenią jak będą
chcieli coś pozmieniać :)

--
Pozdrawiam
Piotrek

do góry

Użytkownik "Piotr Dmochowski" napisał w wiadomości grup
W dniu 2017-02-10 o 15:55, Pszemol pisze:
>> Piotrze, świetne pytanie.
>> Bo to jest ciekawy fragment procesu kasowania pamieci flash i
>> zapisu do
>> niej.
>> Taka pamięć ma wewnątrz sterownik ktory kontroluje te procesy
>> niejako z
>> wewnątrz kostki. Obsługujesz go przez wspólną magistralę danych i
>> adresów -
>> scalak pracuje w dwu trybach: odczyt danych (wtedy działa jak
>> klasyczny

>Widziałem deklarację z volatile, więc wiem że powinny być 2 odczyty.
>Zastanawia mnie jaki jest sens odczytania danych z jednego adresu i
>zrobienie na nich XORa. Jeżeli między jednym a drugim odczytem nie
>będzie zmiany to wynik będzie zerowy i program nie wejdzie do pętli -
>takie jest moje rozumowanie.

Taka ta pamiec - poki sie kasuje, to odczytuje nie dane z pamieci,
tylko rejestr statusu, w ktorym sa dwa "toogle bit".

A jak sie skonczy kasowac, to przestaje migac bitami i petla ma sie
zakonczyc.

>Może w praktyce jakoś to działa, ale zastanawiam się jaki jest
>margines błędu w takim rozwiązaniu.
>Jak najbardziej rozumiem pobranie jednego statusu i sprawdzenie D6,
>bez XOR to nie pójdzie?

Jak odczytasz raz, to nie wiesz czy bit miga, a wiec nie wiesz czy to
rejestr statusu czy dane z pamieci.

J.

do góry