OCTOSPI - wrong code generation? Bug should be fixed.

[CesarH]

Hello,

I am debugging a board which contains the MCU - STM32L4R7VI6 and an HYPERRAM IC connected to the OCTOSPI2 port on the MCU. While generating code on the STM32CUBEMX the tool generates the following code snippet at the bottom of the OCTOSPI_INIT function.

  sMemMappedCfg.TimeOutActivation = HAL_OSPI_TIMEOUT_COUNTER_DISABLE;
  sMemMappedCfg.TimeOutPeriod = 1;
  if (HAL_OSPI_MemoryMapped(&hospi2, &sMemMappedCfg) != HAL_OK)
  {
    Error_Handler();
  }

HAL_OSPI_MemoryMapped should not be initialized here and will execute the Error_Handler() 10/10 times since the sMemMappedCfg array isn't fullfilled at this point. It should be initalized in the main function according to the AN5050 OCTOSPI application PDF when the OCTOSPI2 port have been set to MemoryMapped. This is done in the main() function before HAL_OSPI_MemoryMapped () is called. So every time I generate code using the CubeMX tool I have to delete the snippet of code in the OCTOSPI_init() function.

I found another issue where the RCC clock for the OCTOSPI_IOMANAGER isn't enabled which makes the OCTOSPI2 port set to 0x00 altough the corresponding OSPI_IOM bytes are set in order for the MUX to drive internal OSPI ports to GPIO. The following code should be added at the top of the OCTOSPI_init file or at the RCC_init file.

	RCC->AHB2ENR = (1 << 20);
	RCC->AHB3ENR = (1 << 9);

!!!READ!!!

I can read and write to the HYPERRAM with this configuration.

[Imen.D]

Hello @CesarH​ ,

Which STM32CubeMx version and STM32CubeL4 package are you using ? Please share your ioc file to check this issue.

Kind Regards,

Imen

[CesarH]

Sorry, here it is.

Edit: Didn't read your full request. I am using the new 5.0.x version of the STM32CubeMX with the TrueStudio IDE. This problem occured with the 4.x.x version of CUBEMX too. The MCU is STM32L4R7VIT6 but on the CUBEMX I use the STM32L4R7VITx package as the HAL and CMSIS drivers.

Overall I am very satisfied with the work ST is putting in with the CubeMX, it makes embeded development far more easy and quicker than it would have been if I had to learn the HAL library all by myself through datasheets/PDFs.

[Nesrine.JLASSI · Accepted solution]

​Hi @CesarH​ 

After check, according to the AN5050 OCTOSPI application PDF, the location of the following code is correct, it should be initalized in the main function :

sMemMappedCfg.TimeOutActivation = HAL_OSPI_TIMEOUT_COUNTER_DISABLE;

sMemMappedCfg.TimeOutPeriod = 1;

if (HAL_OSPI_MemoryMapped(&hospi2, &sMemMappedCfg) != HAL_OK)

{

Error_Handler();

}

For the RCC clock and after check, the definition of RCC as clock exists in the stm32l4xx_hal_rcc_ex.h file as shown in the following photo:

 

Regards,

Nesrine