msp430f147 amnesie

[yneg (yet noch ein gast) (Gast)]

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 ?

[Stefan (Gast)]

Ü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!

[yneg (yet noch ein gast) (Gast)]

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

[Stefan (Gast)]

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

[yneg (yet noch ein gast) (Gast)]

> 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

[yneg (yet noch ein gast) (Gast)]

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