I conducted some test in case the option bytes in the STM32L474 (Nucleo 64 board) are set incorrectly for my application. Note HAL is not used (it's a strict bare metal application since this is a home experiment to reduce power consumption to the bare minimal). The correct OB setting is:
I've changed above to SRAM2 parity enabled (that is the config my app doesn't expect and has to correct after reboot). I've declared a static variable that acts a fast indicator SRAM2 was initialized before reset:
static volatile uint32_t __attribute__((section(".sram2"))) initializedRam;
The code simply checks at the start by:
FLASH->OPTR &= ~FLASH_OPTR_SRAM2_PE;
//Tried barriers here, but no effect.
if (initializedRam != MAGIC) //Can still generate NMI although PE is disabled upfront.
{
FLASH->OPTR |= FLASH_OPTR_SRAM2_PE | FLASH_OPTR_SRAM2_RST;
SYSCFG->SKR = 0xCAUL;
SYSCFG->SKR =0x53UL; //Unlock not expected to be required since software erase is performed.
memset ((uint8_t*) (SRAM2_BASE), 0, SRAM2_SIZE);
initializedRam = MAGIC;
}
I understand after power-on-start, the SRAM2 content is undefined. But an NMI was not expected since Parity check is supposed to be disabled prior to the != MAGIC check is performed. Additional statements have all been inserted before that test, but none had any effect):
FLASH->OPTR |= FLASH_OPTR_SRAM2_RST;
PWR->CR3 |= PWR_CR3_RRS;
When I inserted below hardware reset unlock sequence before setting FLASH_OPTR_SRAM2_PE, NMI's where no longer experienced (powered down the controller +5 times; before I experienced NMI in ~60% after POR):
SYSCFG->SKR = 0xCAUL;
SYSCFG->SKR =0x53UL;
This gives the impression RAM2 Parity cannot be disabled once set (except by the hardware reset sequence upfront). This behavior is not mentioned in the L476 documentation (it gives me the impression writing zero to Flash OPTR always disables parity check immediately). Since this is undocumented behavior, I moved initializedRam back to SRAM1 since it has no parity check anyway.
----------------------------------------
Overall the processor documentation vs. HAL implementation is - to my consideration - incomplete (in most cases, if not all MCU types). For instance:
HAL code defines bit combinations b0000 to b1011:
HAL asserts on codes exceeding b1011:
Even if HAL doesn't write binary codes above b1011, the datasheet clearly states ">= 1011" is valid (and has a known behavior). Sometimes a work-around for missing HAL options is to write IO directly (not that I'm in favor, because you this may lead to unexpected behavior). If one writes as such an assumed functional binary code that later on causes an assert that is often very hard to understand/debug. Besides that, I located several cases where HAL implementation is even completely wrong encoding such bits (I encountered cases where the manual stated b11xx are all same functioning as b1100. The HAL code used a series of "?" statements where it ended that as readvalue == CODE_12 ? 12 : 0 -> what is completely wrong since all codes above 11 are considered by hardware to be 12.
