Problemy z programowaniem i kasowaniem dwóch pamięci flash ST M29W640GL z ARM Cortex M4

Thu Feb 09, 2017 5:03 pm   

W dniu 2017-02-08 o 20:31, Pszemol pisze:

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

Fri Feb 10, 2017 10:53 am   

Użytkownik "Pszemol" napisał w wiadomości grup
dyskusyjnych:o7f8jr$e99$1@dont-email.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.

Fri Feb 10, 2017 3:55 pm   

Piotr Dmochowski <imie_nazwisko@poczta.onet.pl> wrote:

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

Fri Feb 10, 2017 5:47 pm   

W dniu 2017-02-10 o 15:55, Pszemol pisze:

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

Fri Feb 10, 2017 5:54 pm   

Użytkownik "Piotr Dmochowski" napisał w wiadomości grup
W dniu 2017-02-10 o 15:55, Pszemol pisze:

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.


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

J.

Fri Feb 10, 2017 7:43 pm   

W dniu 2017-02-10 o 17:54, J.F. pisze:

jest to ok, a jeżeli nie jest i nie wstrzelimy się czasem odczytu to
metoda jest taka sobie.


W programie pecetowym dałbym zmienną w pętli do zapamiętania stanu i
porównywał stan historyczny z aktualnym.
Podejrzewałem że w tym przypadku musi być jakiś haczyk, że może port
procesora jest zmapowany jako miejsce w pamięci, ale do pełni szczęścia
brakuje mi zapewnienia że odczyt portu jest synchroniczny z danymi
wystawianymi przez pamięć, wtedy takie rozwiązanie ma ręce i nogi.

--
Pozdrawiam
Piotrek

Fri Feb 10, 2017 8:05 pm   

Użytkownik "Piotr Dmochowski" napisał w wiadomości
W dniu 2017-02-10 o 17:54, J.F. pisze:

Pszemol wie. Dokumentacja nazywa "toogle bit", to chyba jest, bo
inaczej to by sensu nie mialo :-)


I to IMO i tu jak najbardziej mozna zrobic.
Ale czy trzeba ?
Wychodzi na to, ze Pszemol poprawnie zrobil.


To nie port - to sama pamiec sie tak zachowuje.

Trzeba jakos upchnac funkcje Flash w pinologie zwyklej pamieci
e/ep/rom/ram.

J.

Fri Feb 10, 2017 8:19 pm   

W dniu 2017-02-10 o 20:05, J.F. pisze:

Przy takim rozwiązaniu sprzętowym faktycznie odczytanie dwukrotnie
pamięci jest OK. Czego to się człowiek może nauczyć :)

--
Pozdrawiam
Piotrek

Fri Feb 10, 2017 8:28 pm   

Użytkownik "Piotr Dmochowski" napisał w wiadomości grup
dyskusyjnych:589e122c$0$641$65785112@news.neostrada.pl...
W dniu 2017-02-10 o 20:05, J.F. pisze:

Tez mi sie niespecjalnie podoba, ale czy program bylby
lepszy/czytelniejszy, gdybysmy zrobili z jedna zmienna historyczna ?
Niewiele, zmienne i tak trzeba by dwie.

J.

Fri Feb 10, 2017 9:06 pm   

Piotr Dmochowski <imie_nazwisko@poczta.onet.pl> wrote:

Tak, wartosc tego bitu zmienia sie przy kolejnych odczytach z pamieci.

Fri Feb 10, 2017 9:06 pm   

J.F. <jfox_xnospamx@poczta.onet.pl> wrote:

Stan zmiennej Status1 wskazuje na historyczną wartość zmiennej Status2
)))))

Fri Feb 10, 2017 9:19 pm   

Piotr Dmochowski <imie_nazwisko@poczta.onet.pl> wrote:

Podobnie się zachowują inne kostki pamięci flash - w odróżnieniu od pamięci
RAM (sram, dram) pamięci flash i eeprom można kasować tylko całymi
sektorami (np po 64kbajty) a zapis może się odbywać tylko po wcześniejszym
"odblokowaniu" funkcji zapisu z użyciem wewnętrznego kontrolera w kostce
pamięci.

Jak chcesz więcej poczytać o tej pamięci to tu jest to dokladniej rozpisane
co który bit rejestru statusowego ma znaczyć:

Toggle Bit (DQ6)
The toggle bit can be used to identify whether the program/erase controller
has suc- cessfully completed its operation or if it has responded to an
erase suspend. The toggle bit is output on DQ6 when the status register is
read.During PROGRAM and ERASE operations, DQ6 changes from 0 to 1 to 0,
and so forth, with successive bus READ operations at any address. After
successful completion of the operation, the memory returns to read
mode.During erase suspend mode, DQ6 will output when addressing a cell
within a block be- ing erased. DQ6 will stop toggling when the
program/erase controller has suspended the ERASE operation.The Data Toggle
Flowchart gives an example of how to use DQ6 and the toggle and al-
ternative toggle waveforms describe toggle bit timing.

Alternative Toggle Bit (DQ2)
The alternative toggle bit can be used to monitor the program/erase
controller during ERASE operations. It is output on DQ2 when the status
register is read.During CHIP ERASE and BLOCK ERASE operations, DQ2 changes
from 0 to 1 to 0, and so forth, with successive bus READ operations from
addresses within the blocks being erased. A protected block is treated the
same as a block not being erased. After the oper- ation completes, the
memory returns to read mode.During erase suspend, DQ2 changes from 0 to 1
to 0, and so forth, with successive bus READ operations from addresses
within the blocks being erased. Bus READ operations to addresses within
blocks not being erased will output the memory cell data as if in read
mode.After an ERASE operation that causes DQ5 to be set, DQ2 can be used
to identify which block or blocks have caused the error. DQ2 changes from 0
to 1 to 0, and so forth, with successive bus READ operations from addresses
within blocks that have not erased cor- rectly. DQ2 does not change if the
addressed block has erased correctly.

https://www.micron.com/~/media/documents/products/data-sheet/nor-flash/parallel/m29w/m29w640g.pdf