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