HAL_OSPIM_Config and zero-initialized members of OSPIM_CfgTypeDef

[GModu.1]

I have to configure OCTOSPI2 in Single Mode and only three pins managed directly from peripheral: SI, SO anche CLK.

The code generated from MX is the following:

static void MX_OCTOSPI2_Init(void)
{
  ...
  OSPIM_CfgTypeDef OSPIM_Cfg_Struct = {0};
  ...
  OSPIM_Cfg_Struct.ClkPort = 1;
  OSPIM_Cfg_Struct.IOLowPort = HAL_OSPIM_IOPORT_2_LOW;
  if (HAL_OSPIM_Config(&hospi2, &OSPIM_Cfg_Struct, HAL_OSPI_TIMEOUT_DEFAULT_VALUE) != HAL_OK)
  {
    Error_Handler();
  }

The function HAL_OSPIM_Config() checks validity of all members of OSPIM_Cfg_Struct:

HAL_StatusTypeDef HAL_OSPIM_Config(OSPI_HandleTypeDef *hospi, OSPIM_CfgTypeDef *cfg, uint32_t Timeout)
{
  ...
  /* Check the parameters of the OctoSPI IO Manager configuration structure */
  assert_param(IS_OSPIM_PORT(cfg->ClkPort));
  assert_param(IS_OSPIM_PORT(cfg->DQSPort));
  assert_param(IS_OSPIM_PORT(cfg->NCSPort));
  assert_param(IS_OSPIM_IO_PORT(cfg->IOLowPort));
  assert_param(IS_OSPIM_IO_PORT(cfg->IOHighPort));

So this function fires an assert, because DQSPort and NCSPort are zero, but they should be 1 or 2.

Is this a bug in MX auto-generated code?

[Amel NASRI]

Hello @GModu.1​ ,

I assume that the assert checks applied on HAL_OSPIM_Config (stm32l4xx_hal_ospi.c) should depend on the selected mode to configure the OctoSPI.

This is shared internally with our development team for further check & review.

-Amel