>> weil's kein software problem ist ...
> Sicher???
> Hat die Firmware ein Code-Segment, das den INFO-Flashbereich neu
> beschreiben kann? Dann ist hier sicher auch eine mögliche Fehlerquelle
> zu suchen, denn vor dem neu Beschreiben muss das Flash erst gelöscht
> werden. Wenn Deine "Batterie-Aktion" nun genau dann eine
> Spannungsunterbrechung erzeugt hat, nachdem das Flash bereits gelöscht
> wurde aber bevor der neue Inhalt reingeschrieben werden konnte, dann
> hast Du das gleiche Problem!
war ich einverstanden (s. vorigen post)
andererSeits:
main.c
...
static bool isFlashLeer()
{
byte *flash = (byte *) 0x1000; // Segment pointer
return (flash[1] & flash[2]) == 0xFF; // Kontrolle auf Daten
// ^ original comment, not mine
// BTW: wieso 1 & 2 ? why not 0 & 1 ? oder 3 & 7 ?
}
void main()
{
// init MSP430
...
if (IFG1 & WDTIFG) { // watchDogReset --> POR
IFG1 &= ~WDTIFG;
if (!readParamsFromFlash()) { use_default_params:
getDefaultParams();
writeParamsToFlash(); // nur hier könnt's knallen
// d.h. flash segment erased, dann saft weg
}
}
else { // NOT watchDogReset --> PUC
if (isFlashLeer()) goto use_default_params;
if (!readParamsFromFlash()) goto use_default_params;
}
...
wenn ich den deckel zuschraube, komm ich in den
NOT watchDogReset --> PUC
zweig und da der flash i.d.R. NICHT leer ist (da hab ich ja schon
irgendwann mal meine 'device id' reingeschrieben), könnt's nur
knallen, wenn readParamsFromFlash() NICHT erfolgreich war:
bool readParamsFromFlash()
{
byte *flash = (byte *) 0x1000; // Segment pointer
for (word i=0; i < sizeof data; ++i) data[i] = flash[i];
word CRCinFlash = (flash[sizeof data] << 8) + flash[1 + sizeof data];
return CRCinFlash == wordCRC(data,sizeof data);
}
also wenn checkSumme im flash != der über data kalkulierten
was 'im allgemeinen' nur dann der fall ist, wenn der flash
inhalt 'korrumpiert' wurde...
