2068447_en-US

[#1]

S32K1xx：Frequent access to eeprom sends hardfault

Hello,

    In the development process encountered a problem, frequent access to the S32K118 analog eeprom sent hardfault, I know frequent write eep without delay will occur errors, frequent read will also?

The snippet code is as follows：

    for (uint8 i = 0; i < 16u; i++)

    {

        u8slog[i] = *((uint8 *)(0x14000000) + i) ;

    }

Re: S32K1xx：Frequent access to eeprom sends hardfault

Hi @ZEROOO,

Reading the FlexRAM does not require any delay, even in the EEE mode, it is just an SRAM.

But instead of valid data, the read access can return all 0xFF if there is an ECC error in the backup flash.

So, the application should check if the data are valid before they are processed further.

Writing does not require any delay per se, it requires the CCIF flag to be set before the FlexRAM in the EEE mode can be written.

Regards,

Daniel

Re: S32K1xx：Frequent access to eeprom sends hardfault

Hello,

Yes, frequent reads from the S32K118's analog EEPROM, even without writes, can potentially lead to issues and even hard faults. Here's a breakdown of why and how to mitigate it:

Understanding the S32K118 Analog EEPROM

• Not a Standard Memory: The analog EEPROM on the S32K118 is not like standard RAM or flash. It's an emulated EEPROM using flash memory, and it has specific characteristics that must be considered.
• Limited Endurance: Even read operations can contribute to the wear and tear of the underlying flash memory cells. While reads don't cause the same level of stress as writes, repeated reads over time can still degrade the flash.
• Access Timing: The analog EEPROM access, especially reads, might require specific timing considerations. If reads are performed too rapidly without allowing sufficient time for the memory to stabilize, it can lead to errors.
• Bus Conflicts: Very frequent reads can potentially cause bus conflicts or timing issues, especially if other peripherals or processes are also accessing the memory bus. This can manifest as a hard fault.

Why Frequent Reads Can Cause Issues

1. Flash Wear (Though Minor):

   • While writes are the primary cause of flash wear, repeated reads can also contribute, albeit to a much lesser extent. The flash memory cells are still subjected to electrical stress during read operations.

2. Timing and Bus Contention:

   • The memory controller needs time to access and retrieve data from the flash memory. If reads are performed too rapidly, it might not be able to keep up, leading to data corruption or bus errors.
   • If other peripherals are also accessing the memory bus, frequent reads can exacerbate bus contention, potentially leading to hard faults.

3. Potential for Software Errors:

   • If the read operation is not handled correctly in the software, it can lead to errors. For example, reading beyond the valid address range or not checking for errors can cause issues.

Analyzing Your Code Snippet

for (uint8 i = 0; i < 16u; i++)
{
    u8slog[i] = *((uint8 *)(0x14000000) + i);
}

• This code reads 16 bytes sequentially from the analog EEPROM address range starting at 0x14000000.
• If this code is executed very frequently without any delays, it could contribute to the problems mentioned above.

Mitigation Strategies

1. Introduce Delays:

   • Add small delays between read operations to allow the memory controller to stabilize. The necessary delay will depend on the specific characteristics of the S32K118's analog EEPROM.
   • Example:

     #include "S32K118.h" // Include header file for delay functions.
     for (uint8 i = 0; i < 16u; i++)
     {
         u8slog[i] = *((uint8 *)(0x14000000) + i);
         //Add a small delay.
         for(volatile uint32_t delay = 0; delay < 1000; delay++){} //example delay.
     }

     • Note that the delay amount will need to be tuned for your specific application. Using a timer based delay is preferable to a simple loop delay.

2. Read Less Frequently:

   • If possible, reduce the frequency of read operations. Cache the data in RAM if it doesn't change frequently.

3. Check for Errors:

   • Implement error checking to detect any read errors. The S32K118 might have status registers or flags that indicate memory access errors.

4. Optimize Bus Usage:

   • Minimize bus contention by optimizing the timing of other peripheral accesses.
   • If possible, use DMA to reduce the CPU load during memory access.

5. Refer to the Datasheet:

   • Consult the S32K118 datasheet and reference manual for specific timing requirements and recommendations for analog EEPROM access.

6. Verify Address Range:

   • Ensure that the address range that you are reading from is valid. Reading from an invalid address range will cause a hardfault.