STM32N6 RIF and MMT autoconfiguration errors

[Mikk Leini]

Reporting two issues when using STM32CubeMX v6.16.1 to generate STM32N6 code. I created new secure only template project for STM32N6570-DK to demonstrate the issue (it's attached).

Only changes to the new project are these:

In MMT defined RAM2 area over AXI SRAM3-6. Also check the "Apply Application Regions Settings to Peripherals".

Then activated RIF for FSBL:

Now generate code.

It generates FSBL\Core\Src\main.c function SystemIsolation_Config(void).

There are two function calls that cause assert failure because they violate the HW capability:

 /* set up base region configuration for CPUAXI_RAM0*/
 /* region2 is secure */
 risaf_base_config.EndAddress = 0x1003ff;
 risaf_base_config.StartAddress = 0x00000400;
 HAL_RIF_RISAF_ConfigBaseRegion(RISAF2, RISAF_REGION_2, &risaf_base_config);

 /* set up Sub region configuration for CPUAXI_RAM0*/
 risaf_sub_config.EndAddress = 0xfffff;
 risaf_sub_config.StartAddress = 0x00000400;
 HAL_RIF_RISAF_ConfigSubRegion(RISAF2, RISAF_REGION_2, RISAF_SUBREGION_A, &risaf_sub_config);

The RISAF region 2 and it's subregion A start address is at 0x400 (1 KiB) offset because BootROM requires the FSBL to be there. But inside the HAL_RIF_RISAF_ConfigBaseRegion and HAL_RIF_RISAF_ConfigSubRegion functions is this line:

assert_param(IS_RISAF_GRANULARITY(RISAFx, pConfig->StartAddress));

And it fails (if full asserts are enabled) because RISAF granularity is 0x1000 (4 KiB). And it probably doesn't work properly either if assert is ignored.

Another issue or weirdness is that generated SystemIsolation_Config contains these lines:

 /* Enable NPU Clock */
 __HAL_RCC_NPU_CLK_ENABLE();
 __HAL_RCC_NPU_FORCE_RESET();
 __HAL_RCC_NPU_RELEASE_RESET();

 __HAL_RCC_AXISRAM4_MEM_CLK_ENABLE();
 CLEAR_BIT(RAMCFG_SRAM4_AXI->CR, RAMCFG_CR_SRAMSD);
 __HAL_RCC_AXISRAM5_MEM_CLK_ENABLE();
 CLEAR_BIT(RAMCFG_SRAM5_AXI->CR, RAMCFG_CR_SRAMSD);
 __HAL_RCC_AXISRAM6_MEM_CLK_ENABLE();
 CLEAR_BIT(RAMCFG_SRAM6_AXI->CR, RAMCFG_CR_SRAMSD);

First of all NPU clock enabling is unexpected. I have not enabled it in CubeMX. I guess that since AXISRAM3-6 are designed for NPU (but not only), they are somehow tied. I want to use them for CPU, not NPU. Second weirdness - if it enables AXISRAM4-6 then why not AXISRAM3 ? And finally - why does it put such code here at all? I would prefer to keep the code clean - RIF shall do RIF stuff, not other peripherals enabling. I would like to activate AXISRAM's with AXISRAM peripheral instead, but that comes with a tool bug that I reported here:
CubeMX fails to load IOC file after enabling RAMCF... - STMicroelectronics Community

[Souhaib MAZHOUD]

Hello @Mikk Leini 

Thank you for highlighting this issue.!

I will check this internally with the dedicated team and get back to you ASAP.

KR, Souhaib

[Souhaib MAZHOUD]

Hello @Mikk Leini 

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

BR, Souhaib

[kobyfr]

Hello ​@Souhaib MAZHOUD .

Is there an updated on this issue?
I get a similar problem.

I started from the PWR_STANDBY_RTC example project.
I then added an extra logical RAM1 region over 4 physical RAMs AXI SRAM3-6.
I then generated the STM Cube IDE code, and it added this clock init code for those RAMs:
 

__HAL_RCC_AXISRAM3_MEM_CLK_ENABLE();
CLEAR_BIT(RAMCFG_SRAM3_AXI->CR, RAMCFG_CR_SRAMSD);

__HAL_RCC_AXISRAM4_MEM_CLK_ENABLE();
CLEAR_BIT(RAMCFG_SRAM4_AXI->CR, RAMCFG_CR_SRAMSD);

__HAL_RCC_AXISRAM5_MEM_CLK_ENABLE();
CLEAR_BIT(RAMCFG_SRAM5_AXI->CR, RAMCFG_CR_SRAMSD);

__HAL_RCC_AXISRAM6_MEM_CLK_ENABLE();
CLEAR_BIT(RAMCFG_SRAM6_AXI->CR, RAMCFG_CR_SRAMSD);

which runs fine,
but then it added this region and sub region init code for these 4 segments, and each one crashes the program and I lose the debug connection

 

/* set up base region configuration for NPU_master1*/
/* region1 is secure */
risaf_base_config.EndAddress = 0xbffff;
HAL_RIF_RISAF_ConfigBaseRegion(RISAF5, RISAF_REGION_1, &risaf_base_config);

/* set up base region configuration for CPUAXI_RAM1*/
/* region1 is secure */
risaf_base_config.EndAddress = 0xfffff;
HAL_RIF_RISAF_ConfigBaseRegion(RISAF3, RISAF_REGION_1, &risaf_base_config);

/* set up base region configuration for CPU_master*/
/* region1 is secure */
risaf_base_config.EndAddress = 0x1bffff;
HAL_RIF_RISAF_ConfigBaseRegion(RISAF6, RISAF_REGION_1, &risaf_base_config);

/* set up base region configuration for CPUAXI_RAM0*/
/* region1 is secure */
risaf_base_config.EndAddress = 0xfffff;
risaf_base_config.StartAddress = 0x00080000;
HAL_RIF_RISAF_ConfigBaseRegion(RISAF2, RISAF_REGION_1, &risaf_base_config);

/* region2 is secure */
risaf_base_config.EndAddress = 0x7ffff;
risaf_base_config.StartAddress = 0x00000000;
HAL_RIF_RISAF_ConfigBaseRegion(RISAF2, RISAF_REGION_2, &risaf_base_config);

I checked CubeMX RIF tab, and it seems to populate these new regions:
1. RISAF 3 (CPU AXI RAM1)
2. RISAF 4 (NPU master 0)

so the questions remain:

1. why does the code get generated so, with some kind of invalid region definition?
2. why does the NPU region get involved at all?