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
