Customer: Bosch
XRDC init is triggering a crash, please let us know if any further details are needed
XRDC version : AR release 43. 4.4.0 (SW version 4.0.2)
HSE FW version : 22_2_62_0
RTD Module: RM
Customer's Code:
In M7 Core
Xrdc_Ip_Init(&Xrdc_Config); calling this in Task_Init at last where Xrdc_Config comes from tresos generated file
static const Xrdc_Ip_InstanceConfigType * const aXrdc_Config_Array[1] = {&Xrdc_Config_XRDC_INSTANCE0};
const Xrdc_Ip_ConfigType Xrdc_Config =
{
aXrdc_Config_Array,
(uint32)1UL,
Xrdc_Instances_InUsed,
(uint32)1UL
};
TASK(Task_Init)
{
All the init functions for instance ADC, PFE
Csm_Init(NULL_PTR);
CryIf_Init(NULL_PTR);
Crypto_Init(NULL_PTR);
Xrdc_Ip_Init(&Xrdc_Config);
Could you please help me to figure out the issue in this attached code (EB Tresos) from customer.
Thanks
Dhvani Singhal
Hi @DanNguyenDuy,
I will ask customer to implement this method and send the configuration files to me. Then i will send the files to you.
Thanks
Dhvani Singhal
Hello @DhvaniSinghal,
There is a note in RTD_RM_IM file about Rm_Init. Did you call Mcu_Init() before call Xrdc_Ip_Init()?
If you did that, could you send me the configuration files (.xdm or .arxml files) and let me know what is the statement in Xrdc_Ip_Init() function caused crash?
And from my point of view, you should call Xrdc_Ip_Init() before Crypto_Init().
Best regards,
Dan
Hi @DanNguyenDuy,
Customer asked some questions for XRDC initialization which are given below:
- What is the recommended method for dynamically attaching or changing the Process ID (PID) for a core (M7 or A53) at run-time?
- The XRDC driver is available only at Host side. Is it allowed to modify XRDC registers at A53 side to attach PIDs ?
- How do we ensure safety if we are allowing access to XRDC registers at run time to A53.
- If an A53 core attempts an access that is blocked by the XRDC (i.e., an Access Violation occurs), are there any XRDC status registers or mechanism that can be monitored by the M7 safety core to debug this failure?
- We have observed that XRDC DERLOCK register (Domain Error Lock) sometimes does not appear to update correctly after XRDC failure. Aside from checking this register, where else in S32G3's safety or security blocks can we check for confirmation that an XRDC access failure has occurred and been logged?
- At which specific point in the boot sequence are XRDC restrictions applied to the A53 cores?
- What is the default XRDC policy (e.g., default DID assignment and default access permission) for the A53 cores before the system software configures and locks the XRDC registers?
Could you please help me to provide the response to above questions.
Thanks and Regards
Dhvani Singhal
Hi @DhvaniSinghal,
Question 1:
- 1.1 Yes, it is allowed. The user can call Xrdc_Ip_SetProcessID() from the A53 side to update the PID of the master core.
- 1.2 To ensure safe access at runtime, configure a SEMA42 channel for mutual exclusion. This prevents simultaneous access and guarantees atomic updates to XRDC registers.
Question 2 & 3: currently, there is no mechanism for Cortex-M7 to check error status of Cortex-A53.
Question 4 & 5: please contact the HSE team for these questions.
Best regards,
Dan
Hi @DanNguyenDuy,
Xrdc_Ip_Init called before crypto init
Tried initializing the Rm_Init before Xrdc_Ip_Init by calling it in rba_main
Observing the crash once Rm_Init is added just after Mcu_Init
Regards
Dhvani Singhal
Hi @DhvaniSinghal,
This is correct sequence for Mcu initialization before call Rm_Init.
Additional, because Rm_Init() will call Xrdc_Ip_Init(). So, if user called Rm_Init(), they don't need to call Xrdc_Ip_Init(). Please remove either Rm_Init() or Xrdc_Ip_Init() out of code.
Best regards,
Dan