STM8S103: EEPROM-Write nach Watchdog-Reset verursacht CPU-Lockup ?

[TU Student 1. (student0)]

Kann sich jemand den Code ansehen ?   Sind meine EEPROM-Routinen 
grundsätzlich korrekt?  Ich habe vorsichtshalber auch Flags getestet, 
die eigentlich egal sein müssten.

Ich habe das Problem, dass nach einem(absichtlichen) Watchdog-Reset der 
nächste EEPROM - Schreibzugriff nach dem Reset zu einem kompletten Core 
- Lockup führt.

Manchmal passiert das nicht, wenn etwas über die UART herausgesendet 
wird.

Normale Schreibzugriffe (vor dem Watchdog-Reset) auf das EEPROM 
funktionieren problemlos.

Was ich bereits probiert habe:
- sim()/rim() damit während der Schreibvorgangs kein Interrupt auftritt
- Ca. 10 NOPs nach jedem geschriebenen Byte
- Prüfen des HV-Flags, was bei STM8 Low-Density nicht nötig sein sollte
- Prüfen, ob das EEPROM nicht schreibgeschützt ist, bevor ich die 
MASS-Keys schreibe  (was auch nicht notwendig sein sollte)
- Die CPU-Taktfrequenz vor dem Reset heruntersetzen
(es gibt ein Erratum im Bezug auf Halt-State und Flash-Zugriffe)


Mein Code macht folgendes:
(UART-RX und Timer-Interrupts Aktiv)
1. Flag-Byte im EEPROM setzen.  Das funktioniert
2. Absichtlichen WDT-Reset erzeugen
3. Nach Reboot das Flag prüfen
4. Das Flag resetten -> Hier passiert es.

Auch ohne sim() gibt es einen kompletten CPU-Lockup, denn auch auf 
externe Interrupts wird nicht reagiert (für jedes UART-Byte wird eine 
Board-LED angeschalten und nach 1s durch den Timer, der auch für 
Timeouts zuständig ist, abgeschalten).

unsigned char eeprom_peek(unsigned char offset)
{
  unsigned char *eeprom = 0x4000 + (unsigned char *)offset;
  return *eeprom;
}

void eeprom_poke(unsigned char data, unsigned char offset)
{
  volatile unsigned char *eeprom = 0x4000 + (unsigned char *)offset;
  sim();  // Is this needed?
  // Unlock EEPROM
  if (!(FLASH_IAPSR & (1 << 3))) // Check should not be needed?
  {
    FLASH_DUKR = 0xAE; // First MASS key
    FLASH_DUKR = 0x56; // Second MASS key
    while (!(FLASH_IAPSR & (1 << 3))); // Wait for EEPROM to unlock    
  }
  *eeprom = data;
  while (!(FLASH_IAPSR & (1 << 6))); // Wait for EEPROM to finish, is it needed?    
  // Is this needed on Low-Density STM8  ?!  
  
  FLASH_IAPSR &= ~(1 << 3); // Relock EEPROM
  rim();  // Is this needed?
}

void eeprom_write(unsigned char * data, unsigned char offset, unsigned char size)
{
    volatile unsigned char *eeprom = 0x4000 + (unsigned char *)offset;
    sim();  // Is this needed?
    // Unlock EEPROM
    if (!(FLASH_IAPSR & (1 << 3))) // Check should not be needed?
    {
      FLASH_DUKR = 0xAE; // First MASS key
      FLASH_DUKR = 0x56; // Second MASS key
      while (!(FLASH_IAPSR & (1 << 3))); // Wait for EEPROM to unlock    
    }
  
  while (size--)
  { 
  *eeprom++ = *data++;
    while (!(FLASH_IAPSR & (1 << 6))); // Wait for EEPROM to finish, is it needed?    
  }
  
  FLASH_IAPSR &= ~(1 << 3); // Relock EEPROM
  rim();  // Is this needed?
}

void eeprom_read(unsigned char * data, unsigned char offset, unsigned char size)
{
  volatile unsigned char * eeprom = 0x4000 + (unsigned char * ) offset;
  while (size--)
    *data++ = *eeprom++;
}

unsigned char eeprom_compare(unsigned char * data, unsigned char offset, unsigned char size)
{
  volatile unsigned char *eeprom = 0x4000 + (unsigned char *)offset;
  
  while (size--)
    if ( *data++ != *eeprom++)
      return 0;
  
  return 1;
}

All das hat nichts gebracht, ich habe es zurückgeführt auf den 
Watchdog-Reset - nur dann tritt dieses Problem auf.

Wenn ich statt dem absichtlichen Watchdog-Softreset:

CLK_CKDIVR = 0x06;
IWDG_KR = 0xCC;         //  Start the independent watchdog.
IWDG_KR = 0x55;         //  Allow the IWDG registers to be programmed.
IWDG_PR = 0x06;         //  Prescaler is 2 => each count is 250uS
IWDG_KR = 0xAA;         //  Reset the counter.
while(1);

einen Sprung an den Reset-Vektor mache:

__asm__("jpf 0x8000");

tritt das Problem nicht mehr auf, der Code funktioniert perfekt in der 
Applikation.

Nun habe ich einen Testbench-Code (eeprom.c) geschrieben um das 
Verhalten zu replizieren, und siehe da: Es tritt nicht mehr auf!

Meine Vermutung ist zum derzeitigen Stand:   Es hat irgendwas mit 
Interrupts zu tun oder es ist ein Silicon-Bug, denn der Testbench-Code 
verwendet keine Interrupts, meine Applikation jedoch UART-RX und 
Timer-Interrupts.   Ich schalte jedoch explizit auch die Interrupts ab 
um eventuellen Problemen vorzubeugen.

Weiss einer der STM8/SDCC Gurus (SDCC Maintainer) weiter?

Hab ich etwas nicht beachtet?

[TU Student 1. (student0)]

Der Lockup passiert auch in der Applikation, wenn der Reboot über den 
Window-Watchdog, wie im STM8-CPU-Manual empfohlen, ausgelöst wird:

  WWDG_CR |= (1 << 7);    //  Enable the window watchdog
  WWDG_CR &= ~(1 << 6);   //  Bit 6 cleared triggers
  while(1);

[TU Student 1. (student0)]

Ich bin der Sache näher gekommen - je länger das Delay zwischen 
EEPROM-Unlock und EEPROM-Write ist, desto weniger wahrscheinlich 
passiert der Lockup.

Nach dem Lockup passiert ist reagiert die CPU auch nicht mehr auf 
Interrupts!
(bei jedem UART Byte leuchtet eine LED auf, der Timer macht sie nach 1s 
aus)

Mit diesem Code funktioniert es:

static void delay(unsigned int t)
{
    while (t--)
        ;
}

void eeprom_poke(unsigned char data, unsigned char offset)
{
    unsigned char *eeprom = 0x4000 + (unsigned char *)offset;
    // Unlock EEPROM
  //sim();
  FLASH_DUKR = 0xAE;  // First MASS key
  FLASH_DUKR = 0x56;  // Second MASS key
  delay(1700);
  *eeprom = data;
  FLASH_IAPSR &= ~(1 << 3); // Lock EEPROM
  //rim();
  return;  
}

Offenbar ist das EEPROM-Unlock-Flag (Bit 3 im FLASH_IAPSR) fehlerhaft, 
weil man trotzdem nicht sofort nachdem es 1 wird draufschreiben kann.

Das erklärt auch, warum meine eeprom_write Funktion meistens 
funktionierte, die eeprom_poke Funktion jedoch nicht, da die 
while-Schleife offenbar genug CPU-Takte an  Overhead erzeugt.