Hello @Hamady
CubeMX uses this Boot/Application architecture to enforce clear ownership of sensitive peripherals, especially crypto resources like RNG and HASH, so that initialization, clocking, interrupts, and security attribution remain deterministic, isolated, and maintainable. The main idea is to avoid ambiguous generated code and unintended coupling between the boot domain and the application domain, which is particularly important in secure startup flows. As a consequence, CubeMX allows such peripherals to be assigned to only one context. If both boot and application must use the same peripheral, this is generally not handled by the code generator, and the second context must access it through manual code integration, with the user taking responsibility for proper clock enable, initialization sequence, reset/state handling, security configuration, and safe handover between boot and application.
Thx
Ghofrane
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
