hai leute! bin zum 1. mal hier und 'µC-neuling', also bitte nachSicht walten lassen hab 'devices' mit msp430f147 in dessen info-memory @ 0x1000 ist eine 2-byte 'device id' gespeichert (unsigned short, != 0) das 'device' hat einen nicht empfehlensWerten batterieHalter: man muss ziemlich 'rumFummeln', bis man den deckel zugeschraubt bekommt nach der letzten batterieHalterDeckelRumFummelei hab ich festgestellt, dass die firmware des betreffenden 'device' nicht mehr 'richtig' funktioniert nach langer suche hab ich den grund gefunden: die 'device id' war WEG: *((unsigned short)0x1000) == 0 wie kann sowas passieren ? muss der msp430f147 beim 'hochFahren' bestimmte zeit lang stabile 'energieVersorgung' haben ? und wenn in dieser phase der saft plötzlich aufhört zu fließen (wie bei der 'rumFummelei' mit dem batterieHalterDeckel) ==> sh*t happens ?
Über dieses Problem stolpert man recht häufig bei den älteren F1xx Devices ohne BOR. Hatte selbst schon das "Vergnügen" mit dem F123! Nach Umstellung auf den (damals) neueren F1232 mit BOR war das Thema vom Tisch! Such Dir also -wenn möglich- einen Typ mit BOR aus, am besten gleich einen aus der F2xxx-Familie. Alternativ kannst Du einen externen Reset-Baustein verwenden um das Problem eventuell etwas einzudämmen. Arg viel Hoffnung will ich Dir aber nicht machen! Beim F123 hat das nämlich nicht geholfen, da dieser bei "Unterspannung" gemacht hat was er wollte, egal ob der Reset-Pin von extern gezogen war oder nicht!
> ... Such Dir also -wenn möglich- einen Typ mit BOR aus ... geht leider net :-( > ... Arg viel Hoffnung will ich Dir aber nicht machen! ... nichtdestotrotz: danke, Stefan ein kollege meint, ein ausreichend langes delay vor dem eintreten in die 'haupt-schleife' der firmware würde helfen obwohl ich WENIG ahnung von µCs habe, glaube ich NICHT, dass dies was bringt, weil's kein software problem ist ...
>ein kollege meint, ein ausreichend langes delay vor dem >eintreten in die 'haupt-schleife' der firmware würde helfen Nee, das bringt nichts! Vor der main() wird nur eine compiler-spezifische Initialisierung durchgeführt (sofern man C/C++ programmiert, bei Assembler hat man das selbst in der Hand), aber das INFO-Memory wird dabei nicht angerührt! >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!
> Nee, das bringt nichts! meine worte :-) > Hat die Firmware ein Code-Segment, das den INFO-Flashbereich > neu beschreiben kann? wenn 'Code-Segment' = 'routine', dann jö: void writeDataToFlash() > 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 Spannungs- > unterbrechung erzeugt hat, nachdem das Flash bereits gelöscht > wurde aber bevor der neue Inhalt reingeschrieben werden konnte, > dann hast Du das gleiche Problem! einleuchtend... void writeDataToFlash() { char* flash = (char *) 0x1000; // Flash pointer FCTL1 = FWKEY + ERASE; // Set Erase bit FCTL3 = FWKEY; // Clear Lock bit *flash = 0; // Dummy write to erase Flash segment das wird's wohl sein ? FCTL1 = FWKEY + WRT; // Set WRT bit for write operation for (word i=0; i < sizeof data; ++i) flash[i] = data[i]; FCTL1 = FWKEY; // Clear WRT bit FCTL3 = FWKEY + LOCK; // Reset LOCK bit } btw der original firmware-code ist nicht von mir - unsere hatte 'probleme' mit der hersteller-firma und so bin ich jetzt gezwungen, zu flicken
>> 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...
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.