STM8 Option Bytes während der Laufzeit programmieren - Fehlerhafte Bytes

[chris (Gast)]

Hallo,

ich habe einen STM8S003F3 bei dem ich während der Laufzeit folgendes 
mache:

    FLASH_Unlock(FLASH_MEMTYPE_DATA);
    FLASH_ProgramOptionByte(0x4803, 0x02);
    FLASH_Lock(FLASH_MEMTYPE_DATA);

Nun ist es nach der Zeit vorgekommen das einige Controller nicht mehr 
funktionierten. Ich wollte dann mit dem ST-Link den Controller auslesen 
um zu schauen ob sich der Flash-Inhalt geändert hat. Dabei kam eine 
Meldung vom STVP das die Option Bytes nicht valid sind. Nach dem 
neuprogrammieren der Option Bytes konnte ich das Flash auslesen und 
keine Fehler feststellen, der Controller funktionierte nun auch wieder.

Die Option Bytes haben ja jeweils noch ein inverses Byte. Die 
Programmierroutine programmiert die folgendermaßen:

       /* Program option byte and his complement */
       *((NEAR uint8_t*)Address) = Data;
       *((NEAR uint8_t*)((uint16_t)(Address + 1))) = (uint8_t)(~Data);

Ich habe nun die Vermutung das zwischen den zwei Schreibinstruktionen 
(sind ja mehrere Assembler-Befehle) der Controller von der Versorgung 
getrennt wurde. Das würde die fehlerhaften Option Bytes erklären.

Jedoch steht im Datenblatt wenn das Option Byte mit dem inversen nicht 
übereinstimmt wird der default-Wert für das jeweilige Option Byte 
genutzt. Das wäre dann in meinem Fall nicht programmiert und der Pin 
hätte einfach die Funktion nicht. Der Controller sollte aber trotzdem 
noch laufen.

Kann es sein das der Controller nicht mehr richtig anläuft wenn ein 
Option Byte nicht passt?

Viele Grüße
Chris

[JensK (Gast)]

Hallo Chris,
ich habe genau das gleiche Problem. Bei mir waren auch vier Controller 
"ausgestiegen", mit genau dem gleichen "Symtom" - Option-Byte not valid. 
Von den inversen Bits war eins (das umprogrammierte) nicht invers. Auch 
bei mir wurde dann beim Zugriff aus STVD nicht der Default-Wert benutzt 
sondern mit einer Fehlermeldung abgebrochen. Mit vielen Tricks konnte 
ich die Controller mit STVP "wiederbeleben".
Allerdings programmiere ich nur in Assembler, hier das Option-Bit AFR0:
  mov  FLASH_DUKR,#$AE  ;Unlocking MASS for EEPROM
  mov  FLASH_DUKR,#$56  ;Bestätigung: Unlock. MASS for EEPROM
  mov  FLASH_CR2,#$80  ;Enable option byte write OPT
  mov  FLASH_NCR2,#$7F  ;Bestätigung: Enable option byte write
  mov  OPT2,#%00000001  ;AFR0 auf 1 in OPT2-Register
  mov  NOPT2,#%11111110  ;Bestätigung: AFR0 Remapping
Die beiden (letzten) ASM-Befehle zum Beschreiben der Option-Register 
folgen unmittelbar aufeinander. Es wäre wirklich riesengroßer Zufall, 
würde die Programmierung nach dem erste Befehl unterbrochen.
Bei den meisten anderen Controllern, die mit dem gleichen Programm 
arbeiten, trat/tritt der Fehler nicht auf.
Deshalb vermute ich, es hängt eher mit Locking/Unlocking des EEproms 
zusammen. Was bedeuten die Parameter Deines Befehls:
  FLASH_ProgramOptionByte(0x4803, 0x02);
Ist das sofortige, folgende Sperren zwingend erforderlich?
  FLASH_Lock(FLASH_MEMTYPE_DATA);
Gibt es schon eine Lösung?
Beste Grüße
Jens

[besser ist der MSP (Gast)]

JensK schrieb:
> Was bedeuten die Parameter Deines Befehls

schaust du in die AN2659 von ST

und bei

chris schrieb:
> FLASH_Unlock(FLASH_MEMTYPE_DATA);
>     FLASH_ProgramOptionByte(0x4803, 0x02);
>     FLASH_Lock(FLASH_MEMTYPE_DATA);

fehlt das Löschen:

        FLASH_Unlock(FLASH_MEMTYPE_DATA);

        FLASH_EraseOptionByte(0x4803);
        FLASH_ProgramOptionByte(0x4803, 0x02);

        FLASH_Lock(FLASH_MEMTYPE_DATA);