Electronic – STM32F429 ignoring writes to EXTI mux registers

When you go and look at the features sets for each family for all of the STM32F parts, you will see that a lot of the part families (e.g. STM32F101xx, STM32F102xx and STM32F103xx, STM32F105xx and STM32F107xx, and newer families like STM32F2xx, STM32F3xx etc.) have a battery-backed back-up-registers (BKP), and are in the battery-powered back-up domain, which also contains the Real-Time-Clock (RTC). The battery-supply pins have been on the same pins on every package. Some of those families are over 10 years old. So ST are quite focused on maintaining compatibility within part families, and across generations of comparable families.

Hence, battery-backed registers is a cross-product family feature across many of the STM32F since its earlier families. So software can pretty much rely on it being on more recent families if it was on older generations. Hence it would be easy to port code across families, and the feature would likely be retained for that reason, even if other battery-backed storage were added.

However the BKP is quite a small area (e.g. STM32F101xx, STM32F102xx and STM32F103xx, STM32F105xx and STM32F107xx etc.) have 42 sixteen bit registers stored in 42 32bit words. So they are not even contiguous, and because of that, they are not useful for general purpose variable or code storage. So to use it, you'd need to explicitly store values into each register. This is acceptable if you are just using it to store some state that must survive across power out. However, it isn't as flexible as we might like.

Increasing the size of the backup-registers is not going to help code porting, as the extra space wasn't available in the old code. Their isn't much benefit to mitigating the inconvenience of using the backup registers either, as existing apps have solved that.

Battery-backed SRAM is not available on all STM32F families, it is relatively recent. ST have not had EEPROM on their initial STM32F families, so the BKP area was quite important. However, I can easily imagine some smart marketing person identifying a product niche which would benefit from much more battery backed memory than the registers. Further, make it be a large block of 'proper' memory. This could be used for variables within a program by enabling the linker to use it for variables. It wouldn't need explicit actions to store values in the battery-backed SRAM, it would just happen as a side of effect of the program operating as normal. So it is much easier to use, and can hold much more information.

Summary:
Battery-backed registers have been on STM32F families from some of the earliest families. It was essential as it mitigates lack of EEPROM. I believe it is retained for compatibility and to simplify porting of code and systems to newer STM32 families. In many cases, an old application can be recompiled and linked with new libraries and it will 'just work'

Battery-backed SRAM is a newer innovation for STM32, and is not on older families. It is easier to use than battery-backed registers, more flexible, and much bigger. However, it requires code change to use it, so it makes sense to retain battery backed registers.

Having different power consumption is a benefit, but IMHO, is not the reason there are two different technical approaches. They are their for compatibility or significant improvement.

I have solved your issue by following method.

/* GPIO Ports Clock Enable */
__HAL_RCC_GPIOA_CLK_ENABLE();

/*Configure GPIO pin : PA10 */
GPIO_InitStruct.Pin = GPIO_PIN_10;
GPIO_InitStruct.Mode = GPIO_MODE_IT_RISING;
GPIO_InitStruct.Pull = GPIO_NOPULL;
HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);

LL_EXTI_InitTypeDef EXTIinitStruct = {0};
EXTIinitStruct.Line_0_31 = LL_EXTI_LINE_10;
EXTIinitStruct.LineCommand = ENABLE;
EXTIinitStruct.Mode = LL_EXTI_MODE_IT_EVENT;
EXTIinitStruct.Trigger = LL_EXTI_TRIGGER_RISING_FALLING;
LL_EXTI_Init(&EXTIinitStruct);

HAL_PWR_EnterSTOPMode(PWR_MAINREGULATOR_ON,PWR_SLEEPENTRY_WFE); 
LL_EXTI_DeInit();