0.2% of STM32L412RB stops or operates abnormally when powered on from the power off state.

[Toda]

1. Product Description
The product is an automotive remote controller that uses STM32L412RB as an MCU.
The product uses a rechargeable battery and has a power on/off function for storage and delivery.

2. Problem
Some products (0.2%) stop operating due to MCU Latch up during the power-on process when powering on from the power-off state.
Some products stop operating after initial abnormal operation under the same conditions.
The reason why the operation is judged as MCU Latch up is that when the operation stops, MCU Watchdog reset and external reset do not occur.
Only when MCU VDD is turned OFF and then ON, it returns to normal.

3. Self-review
When checking the voltage of the MCU's VDD in the power-off state of the product, it was confirmed that it gradually increased from 0V to 0.35V.
In the power-off state, leakage current occurred due to the connection for the control of the charging circuit, which flowed to the MCU's port (PC13, PA1), causing the MCU's VDD to increase.
During the self-review, it was determined that the defect was caused by the contents of the recently updated Errata 2.2.11.
We received the improvement code of Errata 2.2.11 through the Korean agency and are applying it.
We have not yet received the defective sample from the Vietnamese factory, so we are not able to test it.

4. Inquiry
The issue is being improved in hardware and software with the Workaround of Errata 2.2.11.

1) Why does the issue of Errata 2.2.11 only occur in some products?
    The product maintains approximately 0.35V in the same power-off state.
    However, the products that have the issue account for approximately 0.2% of all products, making it difficult to detect product defects.

2) Why didn't the issue occur from the beginning?
    Our products have been produced and sold since 2019.
    The issue was first discovered after 2023.
    It has been occurring frequently recently, so the quality team has started reviewing it as an issue.
    Looking at the update history of Errata 2.2.11, it was first updated on October 23, 2023, and was additionally updated on November 22, 2024.
    Is it related?

I am also asking the Korean agency the same question.
I am also here to get a quick answer.

Thank you.

[Sarra.S]

Hello @Toda, 

This issue requires starting a FAR (Failure Request Analysis) with the involvement of the quality team. I assume this is already what you did. You should be in contact with your FAE or local ST representative to continue the procedure.

Based on the errata document, we have only one product revision, and all STM32L412RB devices should be concerned by the limitation.

[waclawek.jan]

> Why does the issue of Errata 2.2.11 only occur in some products?

[for those who read this in the future, where the erratum numbering might have changed: yes, this is the VBAT brownout erratum; in the 'L412 errata named "Corrupted content of the backup domain due to a missed power-on reset after this domain supply voltage drop", confusingly named different than the same erratum in some other STM32]

> Why does the issue of Errata 2.2.11 only occur in some products [and did not occur in older pieces]?

As the erratum hints, the issue depends on particular combination of threshold voltages of the internal transistors, which are process-dependent and vary slightly from chip to chip. Note, that the root problem occurs outside the normal operational envelope of the mcu (particularly VBAT is outside the operational values); the unconditional reset of backup domain after powerup should solve the problem.

JW

[Toda]

Thanks for your reply.

I have an additional request.

Another product of ours uses STM32L152 in the same power supply circuit.

It is said that STM32L152, which has not been issued an errata by the Korean agency and Korea ST, can potentially have the same problem.

It is said that the workaround applied to STM32L412 should be applied to STM32L152 as well.

Then, the same content should be included in the errata for STM32L152.

Don't we also need the basis for the problem resolution?

[Toda]

Thanks for the answer.

Even though there is no similar content in the errata, I was suggested to do the same workaround because it could potentially cause the same issue.

You said "the unconditional reset of backup domain after powerup",
but we are resetting the backup domain after checking the BOR status.

Will this be a problem?

Here is the source code I applied.

void Boot_CheckAndResetBackupDomain(void)

{ // 1) 2) Check RCC_FLAG_BORRST (power-on reset or exit from shutdown)?
if (__HAL_RCC_GET_FLAG(RCC_FLAG_BORRST) != RESET)

{
/* a) Enable PWR clock: set PWREN bit in RCC_APB1ENR1 */
RCC->APB1ENR1 |= RCC_APB1ENR1_PWREN; /*
*OR
* // Enable PWR clock
* __HAL_RCC_PWR_CLK_ENABLE();
*/

/* b) Enable access to the backup domain: set DBP bit in PWR_CR1 */
PWR->CR1 |= PWR_CR1_DBP;
/*
*OR
* // Enable access to backup domain
HAL_PWR_EnableBkUpAccess();
*/

/* c.i) Reset backup domain by setting BDRST */
RCC->BDCR = 0x00010000U; // BDRST = 1, all other BDCR bits cleared

/* c.ii) Read back to ensure the reset pulse is long enough */
__NOP();__NOP();__NOP();__NOP(); // brief delay
// ensure write complete
__IO uint32_t temp;
temp = RCC->BDCR;
UNUSED(temp);

/* c.iii) Clear BDRST to release backup domain out of reset */
RCC->BDCR = 0x00000000U;

/* d) Clear the BORRSTF (brown-out reset) flag: set RMVF in RCC_CSR */
RCC->CSR |= RCC_CSR_RMVF;
/*
*OR
* // Clear BORRSTF
* __HAL_RCC_CLEAR_RESET_FLAGS();
*/
}
}

[waclawek.jan]

> we are resetting the backup domain after checking the BOR status

That's OK, to distinguish the power-on reset from wakeup from standby.

JW