CubeMX fails to load IOC file after enabling RAMCFG

[Mikk Leini]

There's a bug in latest STM32CubeMX v6.16.1. When enabling RAMCFG for Appli on STM32N6 MCU, the IOC file becomes unloadable.

I attached the demonstration IOC file. I created new project for STM32N6570-DK board, enabled RAMCFG peripheral for Appli, checked the AXISRAM3-6 areas, defined single continuous area for those SRAMs in MMT and saved the project. After this CubeMX fails to load this IOC file. I get popup:

In textual form the error is: Cannot invoke "com.st.microxplorer.mcu.memorymap.MemoryMapService.getInRangeAppRegions(long, long, com.st.microexplorer.mcu.Context)" because "this.mMemoryService" is null.

The workaround is to not enable RAMCFG in CubeMX, rather control the peripheral manually.

[Souhaib MAZHOUD]

Hello @Mikk Leini 

Thanks for posting in STCommunity!

Was your project created with version 6.16.1 or was it migrated from an ancient version of CubeMX?

KR, Souhaib

[Mikk Leini]

Attached is a brand now project created today morning to rule out any other cause for the issue.

[Souhaib MAZHOUD]

Hello @Mikk Leini 

I appreciate your clarification. The issue has been reported to the dedicated team for internal investigation and resolution. (Ticket 225670 This is an internal tracking number and is not accessible or usable by customers.)

BR, Souhaib

[Souhaib MAZHOUD · Accepted solution]

Hello @Mikk Leini 

Issue is fixed in the latest STM32CubeMX release 6.17.0 available here.

KR, Souhaib

[Mikk Leini]

Confirming that CubeMX loading problem has been fixed.

But I need to point out that RAMCFG enabling still comes with issue:

AXISRAM clocks enabling code is not generated. As I wrote in another post, clocks are partially enabled by RIF code: STM32N6 RIF and MMT autoconfiguration errors - STMicroelectronics Community

But AXISRAM3 clock is not enabled, so firmware halts. And power needs to be enabled also.

My workaround is to enable all the AXISRAM clocks and power in HAL_RAMCFG_MspInit:

void HAL_RAMCFG_MspInit(RAMCFG_HandleTypeDef* hramcfg)
{
    /* USER CODE BEGIN RAMCFG_MspInit 0 */

    /* USER CODE END RAMCFG_MspInit 0 */
    /* Peripheral clock enable */
    __HAL_RCC_RAMCFG_CLK_ENABLE();
    /* USER CODE BEGIN RAMCFG_MspInit 1 */

    /* AXI SRAM1-2 is already enabled by BootROM.
     * Enable AXI SRAM3-6 clocks manually because CubeMX doesn't do it. */
    __HAL_RCC_AXISRAM3_MEM_CLK_ENABLE();
    __HAL_RCC_AXISRAM4_MEM_CLK_ENABLE();
    __HAL_RCC_AXISRAM5_MEM_CLK_ENABLE();
    __HAL_RCC_AXISRAM6_MEM_CLK_ENABLE();

    /* Power the RAMs */
    RAMCFG_SRAM3_AXI_NS->CR &= ~RAMCFG_CR_SRAMSD;
    RAMCFG_SRAM4_AXI_NS->CR &= ~RAMCFG_CR_SRAMSD;
    RAMCFG_SRAM5_AXI_NS->CR &= ~RAMCFG_CR_SRAMSD;
    RAMCFG_SRAM6_AXI_NS->CR &= ~RAMCFG_CR_SRAMSD;

    /* USER CODE END RAMCFG_MspInit 1 */

}

Another issue is that this function is called 4 times from this path because there are 4 memory areas:

main() -> MX_RAMCFG_Init() +--> HAL_RAMCFG_Init() -> HAL_RAMCFG_MspInit()
                           +--> HAL_RAMCFG_Init() -> HAL_RAMCFG_MspInit()
                           +--> HAL_RAMCFG_Init() -> HAL_RAMCFG_MspInit()
                           \--> HAL_RAMCFG_Init() -> HAL_RAMCFG_MspInit()

It's not a big deal, but in embedded world feels a bit unclean.