Bus trap error while debugging on TC264

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
User16544
Level 1
Level 1
Hello,

1. We integrated application project using
- iLLD driver version: 1.0.1.11.0
- Windriver Compiler Version : 5.6.9.3
- Compiler specific files from Software framework tools: SWFramework_3v1r0___p1,
Release version: 3.1.r0_p1
Release date:08.09.2016

2. We debug the project using Windriver workbench 4.7.3 using onboard DAS USB miniwiggler and iSystem plugin.

3. When we loaded project without running to core0_main , we got CPU bus trap errors. On debugging, we found that it was because of calls related to watchdog in IfxCpu_CStart0.c
from _Core0_start function. We commented the following lines as per the code snippet below.

4. After that we are still getting a CPU bus trap error when the Ifx_C_Init() function is executed in IfxCpu_CStart0.c. Please see code snippet below of _Core0_start function :


void _Core0_start(void)
{
//uint16 cpuWdtPassword = IfxScuWdt_getCpuWatchdogPasswordInline(&MODULE_SCU.WDTCPU[0]);



/* Clear the ENDINIT bit in the WDT_CON0 register, inline funtion */
// IfxScuWdt_clearCpuEndinitInline(&MODULE_SCU.WDTCPU[0], cpuWdtPassword);

// IfxScuWdt_setCpuEndinitInline(&MODULE_SCU.WDTCPU[0], cpuWdtPassword);

/*CPU and safety watchdogs are enabled by default, C initialization functions are not servicing the watchdogs */
#if 0
uint16 safetyWdtPassword = IfxScuWdt_getSafetyWatchdogPassword();
IfxScuWdt_disableCpuWatchdog(cpuWdtPassword);
IfxScuWdt_disableSafetyWatchdog(safetyWdtPassword);
#endif
Ifx_C_Init(); /*Initialization of C runtime variables */
#if 0
IfxScuWdt_enableCpuWatchdog(cpuWdtPassword);
IfxScuWdt_enableSafetyWatchdog(safetyWdtPassword);
#endif
}

}


5. Can you help us with the above .
We see that Ifx_C_Init() function calls the __init_main() function provided by Windriver compiler and this fails with the following bus trap
* Class 4, TIN 1/2. The location of this error changes based on the size of the code.
0 Likes
6 Replies
NeMa_4793301
Level 6
Level 6
10 likes received 10 solutions authored 5 solutions authored
Hi harshajk. The ENDINIT and Safety ENDINIT mechanisms are required to write to protected registers. The application will not work if you comment those calls out.

If you restore the code to the original state, please check the address of the fault in the DEADD special function register. I suspect perhaps your Context Save Area isn't set up yet.
0 Likes
User16544
Level 1
Level 1
Thanks,

* We restored the code to the original state i.e., with ENDINIT and Safety ENDINIT mechanisms enabled.
* With this, we started getting trap in the __init_main function in WindRiver for initializing of data and bss sections. We observe Class 4, Tin 1 with DEADD for CPU0 and CPU1 = 0x0.
* In this above case we have seen that the below code for initializing CSA was called before the __init_main was called.

IfxCpu_initCSA((uint32 *)__CSA(0), (uint32 *)__CSA_END(0));     /*Initialize the context save area for CPU0 */



Regards,
~harshajk
0 Likes
NeMa_4793301
Level 6
Level 6
10 likes received 10 solutions authored 5 solutions authored
If the trap occurs on the call to __init_main, I suspect the local stack pointer isn't initialized properly.

If the trap occurs within __init_main, there's a problem in your linker - e.g., a section that isn't defined, overlapping sections, etc. Address 0 is never valid on the AURIX architecture. Do you see any .data or .bss sections mapped to address 0 in your map file?
0 Likes
User16544
Level 1
Level 1
CSA and CSA_END are mapped as below in CPU0 DSPR for CPU0 as follows :
__CSA0 7000fc00
__CSA0_END 70011c00
0 Likes
User16544
Level 1
Level 1
We have the Stack pointer initialized. We see that other function calls before the _init_main() succeeds with the Stack pointer getting updated appropriately. Hence we don't suspect the stack pointer initialization.

Also, the address for data and bss is mapped to DSPR and hence we don't see any mapping at 0x0.
0 Likes
NeMa_4793301
Level 6
Level 6
10 likes received 10 solutions authored 5 solutions authored
For class 4, TIN 1, check CPUx_PSTR. But that'll probably just tell you that FBE is set (trying to fetch from an invalid address).

Is __init_main being called via CALL, or via FCALL?

If it's via CALL: single-step into __init_main, and set a data breakpoint within the CSA that contains the return address, to make sure it's not getting overwritten inside __init_main.

If it's via FCALL: single-step into __init_main, and set a data breakpoint on the location of the return address on the stack, to make sure it's not getting overwritten inside __init_main.
0 Likes