Board damage during EEPROM emulation write with MCSDK (STEVAL-IHM045V1 + STM32F303

[kumarairia]

Subject: Critical issue: Board damage during EEPROM emulation write with MCSDK (STEVAL-IHM045V1 + STM32F303)

In Hello Experts,

I am working with STEVAL-IHM045V1 power board and STM32F303 evaluation board, running MCSDK (FOC, PMSM, dual motor).

Mcsdk 6.41

Current control approach

• I am using ProgramTorqueRamp() instead of ProgramSpeedRamp() because speed mode causes audible noise and instability at low speeds.

• Motors run normally under wall control.

• Wall control uses 1-wire USART-based communication customized.

• User sets a PWM-like value from wall control, which I map to a torque reference. 
  By calling  Mcacknowledge(); ProgramTorqueRamp(torque_ref, 4000);  startmotor(); in the while loop

• Target - The user-selected pwm value must be stored using EEPROM emulation (Flash write).                   Example user can set any pwm, in Speed 1 pwm 25 , speed 2 pwm 45, speed 3, pwm 65 , speed 4 pwm 75, speed 5 pwm 100

Critical problem

When I attempt to write EEPROM emulation while the motors are running, the system:

• Sometimes triggers watchdog reset

• In several cases physically damages (blows) the power board

If I do not write EEPROM, the motors run fine at all speed and fixed pwm.
If I delay EEPROM write, watchdog reset still occurs in some cases.

My understanding so far

• Flash / EEPROM emulation write blocks CPU execution.

• SysTick and MC background tasks may stop.

• PWM update / FOC timing may break, potentially causing unsafe inverter states.

• Watchdog reset during Flash write may leave PWM outputs undefined.

Questions

1. What is the ST-recommended safe method to store user parameters (torque / PWM setting) when using MCSDK?

2. Is it mandatory to stop the motor and disable PWM outputs before any Flash / EEPROM write?

3. For torque mode using ProgramTorqueRamp(), what is the recommended way to map a user PWM input to torque reference?

4. On STEVAL-IHM045V1:

   • Is the gate driver hardware guaranteed to be OFF during MCU reset or Flash write?

   • Is additional hardware PWM inhibit required?

5. Is there a reference implementation or application note for:

   • EEPROM emulation with MCSDK

   • Safe NVM writes without risking power stage damage?

This issue is urgent, as repeated EEPROM writes are leading to hardware failure.

Any guidance, reference design, or recommended architecture would be greatly appreciated.

Thank you for your support.

Best regards,

[GMA]

Hello @kumarairia,

As you mentioned, "I do not write to EEPROM; the motors run fine at all speeds and with fixed PWM", this indicates that the issue is not related to motor control.
Did you check the "3.5 Real-time consideration" chapter of EEPROM-EMULATION Application Note AN4056 ?

[kumarairia]

Hello GMA,

Firstly, I want to be confirmed from your side that the way i am giving PWM is acceptable.

 

 

Thank you for your clarification and for pointing me to Section 3.5, Real-time consideration, of AN4056.

I understand that EEPROM emulation uses internal Flash and that Flash erase/write operations can stall code execution and block interrupts, which may impact applications with real-time constraints.

To avoid this, I would like to confirm whether it is acceptable to perform EEPROM write operations only when the motor is fully stopped (i.e., PWM disabled and motor control tasks inactive), rather than relocating the vector table and critical code to RAM.

If this approach is acceptable, could you please advise:

• Whether this is the recommended practice for motor-control-based applications, and

• If there are any specific guidelines or example code patterns you would suggest for safely triggering EEPROM writes in the “motor stopped” state.

Your guidance will help ensure a robust and simple implementation while respecting real-time constraints.

int main(void)
{
 /* USER CODE BEGIN 1 */
 /* USER CODE END 1 */

 /* MCU Configuration--------------------------------------------------------*/
 /* Reset of all peripherals, Initializes the Flash interface and the Systick. */
 HAL_Init();

 /* USER CODE BEGIN Init */
 /* USER CODE END Init */

 /* Configure the system clock */
 SystemClock_Config();

 /* USER CODE BEGIN SysInit */
 /* USER CODE END SysInit */

 /* Initialize all configured peripherals */
 MX_GPIO_Init();
 MX_ADC1_Init();
 MX_ADC2_Init();
 MX_ADC3_Init();
 MX_ADC4_Init();
 MX_COMP1_Init();
 MX_COMP2_Init();
 MX_COMP3_Init();
 MX_COMP4_Init();
 MX_COMP5_Init();
 MX_COMP6_Init();
 MX_DAC1_Init();
 MX_OPAMP1_Init();
 MX_OPAMP2_Init();
 MX_OPAMP3_Init();
 MX_OPAMP4_Init();
 MX_TIM1_Init();
 MX_TIM8_Init();
 MX_MotorControl_Init();

 /* Initialize interrupts */
 MX_NVIC_Init();
 // Initial motor start

 // Fault handling flags
 uint8_t M1_faultHandled = 0;
 uint8_t M2_faultHandled = 0;

 while(1)
 {
 static uint32_t lastTick = 0;
 if(HAL_GetTick() - lastTick >= 100)
 {
 lastTick = HAL_GetTick();

 // Update debug info
 dbg.M1_CurrentFaults = Mci[M1].CurrentFaults;
 dbg.M1_PastFaults = Mci[M1].PastFaults;
 dbg.M1_State = Mci[M1].State;
 dbg.M1_RPM = MC_GetAverageMecSpeedMotor1_F();
 dbg.M1_phcurrent = MC_GetPhaseCurrentAmplitudeMotor1();
 dbg.M1_phVol = MC_GetPhaseVoltageAmplitudeMotor1();
 
 dbg.M2_CurrentFaults = Mci[M2].CurrentFaults;
 dbg.M2_PastFaults = Mci[M2].PastFaults;
 dbg.M2_State = Mci[M2].State;
 dbg.M2_RPM = MC_GetAverageMecSpeedMotor2_F();
 dbg.M2_phcurrent = MC_GetPhaseCurrentAmplitudeMotor2();
 dbg.M2_phVol = MC_GetPhaseVoltageAmplitudeMotor2();

 // Acknowledge faults
 MC_AcknowledgeFaultMotor1();
 MC_AcknowledgeFaultMotor2();
 
 // Speed ramp commands
 MC_ProgramTorqueRampMotor1_F(0.70, 4000); // Motor1
 MC_StartMotor1();

 MC_ProgramTorqueRampMotor2_F(0.70, 4000); // Motor2
 MC_StartMotor2();
 
 #ifndef _DEBUG_POWER_RPMMONITOR
 LiveMotorData_Update();
 #endif
 }
 }
}

Best Regards,

---

Edited to apply source code formatting - please see How to insert source code for future reference.

[Andrew Neil]

---

@kumarairia wrote:

I understand that EEPROM emulation uses internal Flash and that Flash erase/write operations can stall code execution and block interrupts, which may impact applications with real-time constraints.,

---

Correct.

 

---

@kumarairia wrote:

To avoid this, I would like to confirm whether it is acceptable to perform EEPROM write operations only when the motor is fully stopped (i.e., PWM disabled and motor control tasks inactive)

---

Of course - if there are no real-time operations taking place, then they cannot be impacted!

You’re right to be concerned Flash writes during active FOC are risky on F3 since CPU stalls can break PWM timing. ST usually recommends stopping the motor, disabling outputs, and servicing the watchdog before any NVM write, or deferring saves until a safe state. I’ve seen similar MCSDK discussions summarized clearly on daulat 777 login.