Skip to main content
Visitor II
June 13, 2026
Question

SPC58 EEPROM Emulation - Flash Erase Blocking Behavior During Block Swap and Watchdog Considerations

  • June 13, 2026
  • 0 replies
  • 5 views

Hello,

We are currently evaluating the EEPROM Emulation package provided for SPC58 devices and would like to understand the intended production usage regarding flash erase operations during block swap.

While reviewing the EEPROM emulation source code, we observed the following call flow:

eeprom_write()
    └─ eeprom_blockswap()
           └─ eeprom_lld_flasherase()

Inside eeprom_lld_flasherase() we found the following implementation:

/* Erase the block */
returnvalue = FlashErase(&ssdConfig,
                         C55_ERASE_MAIN,
                         lowBlockSelect,
                         midBlockSelect,
                         highBlockSelect,
                         nLargeBlockSelect);

if (C55_OK != returnvalue) {
    return FLASH_ERROR_ERASE;
}

/* Wait for completion */
while (C55_INPROGRESS ==
       FlashCheckStatus(&ssdConfig,
                        C55_MODE_OP_ERASE,
                        &result,
                        &dummyCtxData))
{
}

if (C55_OK != result) {
    return FLASH_ERROR_ERASE;
}

From our understanding, this implementation is completely blocking:

No timeout mechanism
No watchdog servicing
No callback execution
No return to application scheduler until erase completion

Our concern is related to EEPROM block swap operations.

When a block becomes full:

EEPROM emulation initiates a block swap.
Valid records are copied to a new block.
The target block may be erased.
eeprom_lld_flasherase() waits inside FlashCheckStatus() until completion.

In applications using a hardware watchdog, the erase duration could potentially become longer than the watchdog timeout period, especially if watchdog servicing is performed from a periodic task or interrupt.

We also found community discussions where flash erase operations on SPC5 devices required hundreds of milliseconds and could trigger watchdog resets if not handled properly.

Therefore we would like to understand the intended usage model.

Questions:

Is this blocking polling loop the officially intended production implementation for SPC58 EEPROM Emulation?
Is there an updated EEPROM Emulation package or newer LLD version that supports non-blocking erase/program operations?
Is it recommended to service the watchdog while waiting for FlashCheckStatus() to complete?
If watchdog servicing is expected, what is the recommended implementation method?
Are there any application notes describing watchdog considerations during EEPROM block swap operations?
Have there been any known field issues related to watchdog resets occurring during EEPROM emulation maintenance activities such as block swap or cleanup?
Is there a recommended minimum watchdog timeout value when using the EEPROM Emulation package?

Our main objective is to understand the officially recommended strategy for watchdog handling during EEPROM block swap operations in production automotive applications.

Any guidance from ST engineers or users with field experience would be greatly appreciated.

Thank you.