MX_FMC_Init() Causes a Hard Fault on NUCLEO-L552ZE-Q

[Zaher]

Hello everyone,

I was wondering what might be the reason for the MX_FMC_Init() function to cause a Hard Fault on the NUCLEO-L552ZE-Q. The code was generated for MDK-ARM IDE by CubeMX 6.4.0 and latest firmware package for that series.

Right now, the NUCLEO board is not connected to anything at all. And I have tested with a brand new project with only the most basic peripherals/middlewares enabled like RCC, GPIO, and of course the FMC.

After spending two hours to figure it out, I found that the code throws hard fault interrupt only when the type of memory selected is "NOR Flash".

What follows is the initialize code for the FMC:

/* FMC initialization function */
static void MX_FMC_Init(void)
{
 
 /* USER CODE BEGIN FMC_Init 0 */
 
 /* USER CODE END FMC_Init 0 */
 
 FMC_NORSRAM_TimingTypeDef Timing = {0};
 FMC_NORSRAM_TimingTypeDef ExtTiming = {0};
 
 /* USER CODE BEGIN FMC_Init 1 */
 
 /* USER CODE END FMC_Init 1 */
 
 /** Perform the NOR1 memory initialization sequence
 */
 hnor1.Instance = FMC_NORSRAM_DEVICE;
 hnor1.Extended = FMC_NORSRAM_EXTENDED_DEVICE;
 /* hnor1.Init */
 hnor1.Init.NSBank = FMC_NORSRAM_BANK1;
 hnor1.Init.DataAddressMux = FMC_DATA_ADDRESS_MUX_DISABLE;
 hnor1.Init.MemoryType = FMC_MEMORY_TYPE_NOR;
 hnor1.Init.MemoryDataWidth = FMC_NORSRAM_MEM_BUS_WIDTH_16;
 hnor1.Init.BurstAccessMode = FMC_BURST_ACCESS_MODE_DISABLE;
 hnor1.Init.WaitSignalPolarity = FMC_WAIT_SIGNAL_POLARITY_LOW;
 hnor1.Init.WaitSignalActive = FMC_WAIT_TIMING_BEFORE_WS;
 hnor1.Init.WriteOperation = FMC_WRITE_OPERATION_ENABLE;
 hnor1.Init.WaitSignal = FMC_WAIT_SIGNAL_DISABLE;
 hnor1.Init.ExtendedMode = FMC_EXTENDED_MODE_ENABLE;
 hnor1.Init.AsynchronousWait = FMC_ASYNCHRONOUS_WAIT_DISABLE;
 hnor1.Init.WriteBurst = FMC_WRITE_BURST_DISABLE;
 hnor1.Init.ContinuousClock = FMC_CONTINUOUS_CLOCK_SYNC_ONLY;
 hnor1.Init.WriteFifo = FMC_WRITE_FIFO_ENABLE;
 hnor1.Init.NBLSetupTime = 0;
 hnor1.Init.PageSize = FMC_PAGE_SIZE_NONE;
 hnor1.Init.MaxChipSelectPulse = DISABLE;
 /* Timing */
 Timing.AddressSetupTime = 15;
 Timing.AddressHoldTime = 15;
 Timing.DataSetupTime = 255;
 Timing.DataHoldTime = 0;
 Timing.BusTurnAroundDuration = 15;
 Timing.CLKDivision = 16;
 Timing.DataLatency = 17;
 Timing.AccessMode = FMC_ACCESS_MODE_B;
 /* ExtTiming */
 ExtTiming.AddressSetupTime = 15;
 ExtTiming.AddressHoldTime = 15;
 ExtTiming.DataSetupTime = 255;
 ExtTiming.DataHoldTime = 0;
 ExtTiming.BusTurnAroundDuration = 15;
 ExtTiming.CLKDivision = 16;
 ExtTiming.DataLatency = 17;
 ExtTiming.AccessMode = FMC_ACCESS_MODE_B;
 
 if (HAL_NOR_Init(&hnor1, &Timing, &ExtTiming) != HAL_OK)
 {
 Error_Handler( );
 }
 
 /* USER CODE BEGIN FMC_Init 2 */
 
 /* USER CODE END FMC_Init 2 */
}

Zaher

[Imen.D]

Hello @Zaher​ ,

Check the FMC clock configuration and if the FMC is properly initialized.

Check the register settings for that you can import an FMC example from STM32CubeL5 and compare the register between your project and working example:

STM32Cube_FW_L5_V1.4.0\Projects\STM32L552E-EV\Examples\FMC

Imen

[Zaher]

Hi @Imen DAHMEN​ 

Yep, the clock is configured properly and the FMC, as well. I didn't check the example projects yet but I will see if there's one for "NOR Flash". Anyways, I changed the memory type to "PSRAM" and re-generated the code and now it works. I don't think there's a big difference in the functions/access modes, or even timing between NOR and PSRAM from the FMC perspective.

[Zaher]

By the way, the clock source on the NUCLEO-L552ZE-Q board is generated internally from HSI RC. Do you recommend the same condition on the final board? How reliable is the HSI RC in generating precise timing as a default clock source in the end product?