Måste flash.minnet rensas före programmering?

[Dalmas]

Har en processor som ingår i en produkt som ska slutprovas. Första steget är att programmera den. Det görs i sekvensen, Rensa, programmera, verifiera. Frågan är; Måste den rensas först? Skrivs inte minnet över med det nya om det nu inte är "rent" från annan kod?
Jag måste få ner totala tiden för denna fas.

[AndLi]

Nej, flash kan bara gå från 1-> 0 vid skrivning, ända sättet att komma tillbaka till 1 är via erase.

Det sagt så kan du oftast tex skriva 0xF5 på en adress för att senare skriva 0x55 och sen 0x51..

Du kan ju göra antagande att ett minne från fabrik är tomt.. skulle det inte vara det så plockas det i verify steget.

Du kan säkert också styra hur mycket minne du ska erasea så du bara rensar det du tänker skriva till.

[Glenn]

Min multiprogrammerare vägrar att programmera om den inte får göra en erase eller blankcheck innan programmering, så man vill nog inte chansa.

[Icecap]

Om det är fabriksnya kretsar kan det räcka med en Blank Check som första steg, är den inte ren måste det ske en radering först.

[Dalmas]

Fick reda på att det ligger en testprogramvara på Flashen innan den hamnar i slutprovningsutrustningen. Så det blev beslutat att det måste ske en erase före.
En annan sak, i processorns manual står det ett värde n(write) = 2. Dvs, 2 skrivningar innan du måste göra en erase. Det fattar inte jag med tanke på vad ni sagt.

[Klas-Kenny]

Låter som du missuppfattat något i databladet. Vilken processor är det frågan om?

[Icecap]

Jag tror att det betyder att det kan göras 2 programmeringar med en radering mellan och Data Retention Time fortfarande är giltig.

Översatt: man kan lägga in testprogram, radera o lägga in det skarpa program och kretsen är fortfarande som ny.

Men programmerar man om fler gångar (utveckling, debugging osv.) ska den inte ut till kund då man inte kan garantera hur länge programmet är stabilt.

[xxargs]

EEprom typiskt 256 byte i processorer (som PIC) kan man skriva med ny data på bytenivå, men flash-minne är mer som gamla Eprom med fönster att man man bara kan skriva 1 -> 0 men inte åt andra hållet utan måste raderas i block om x antal Kilobyte i stöten (precis som när man raderade hela eprommet med UV-ljus)

Tar verkligen flash-raderingen så lång tid att det blir väsentlig tidsförbrukare i hela programmerings-sekvensen ??? - normalt är det själva programmeringen och verifieringen efter som tar tid medans flash-raderingen brukar gå på bara enstaka sekunder för flashminnen typisk PIC-processor.

[Nerre]

Om man tycker det tar för lång tid är det väl en vettig lösning att parallellisera? D.v.s. radera flera stycken parallellt.

Det kan ju antagligen även gå att programmera parallellt (om alla ska ha samma program), men verifieringen är svår att parallellisera.

[Dalmas]

Det är en NRF-(minns ej numret) från Nordic Semi. Ganska avancerad processor.

Ok. Det där med n(write) handlar om hur ofta den kan programmeras om (med eller utan erase) för att garanteras hålla applikationen?

Det går inte att rensa/programmera parallellt som utrustningen är gjord nu.

[AndLi]

Du kan inte programmera om utan att erasea om det inte bara handlar om att sätta 1 till 0 or...

Och det kan vara detta steg som är begränsat du kan alltså bara skriva nya nollor till samma byte ett visst antal gånger innan erase

Vad säger databladet mer exakt när de beskriver det värdet?