infineon4engi@twitter infineon@linkedin infineon4engineers infineon@youtube
twitter Facebook Linkedin Youtube

Banner_AURIX_Security-Solution Banner_AURIX_Safety_Products ShieldBuddy TC275 Banner_AURIX_OnzerOS Banner_AURIX_DevelopmentStudio


+ Reply to Thread
Results 1 to 7 of 7

Thread: Bus trap error while debugging on TC264

  1. #1
    New Member New Member harshajk is on a distinguished road
    Join Date
    Feb 2019
    Posts
    7
    Points
    120

    Bus trap error while debugging on TC264

    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 :

    Code:
    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.
    Last edited by harshajk; Jan 21st, 2020 at 05:31 AM. Reason: provided more clarity,

  2. #2
    Advanced Advanced UC_wrangler will become famous soon enough
    Join Date
    Jun 2019
    Posts
    101
    Points
    2105
    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.

  3. #3
    New Member New Member harshajk is on a distinguished road
    Join Date
    Feb 2019
    Posts
    7
    Points
    120
    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.

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

    Regards,
    ~harshajk
    Last edited by harshajk; Jan 22nd, 2020 at 03:12 AM. Reason: updated description

  4. #4
    Advanced Advanced UC_wrangler will become famous soon enough
    Join Date
    Jun 2019
    Posts
    101
    Points
    2105
    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?
    Last edited by UC_wrangler; Jan 22nd, 2020 at 05:11 AM.

  5. #5
    New Member New Member harshajk is on a distinguished road
    Join Date
    Feb 2019
    Posts
    7
    Points
    120
    CSA and CSA_END are mapped as below in CPU0 DSPR for CPU0 as follows :
    __CSA0 7000fc00
    __CSA0_END 70011c00

  6. #6
    New Member New Member harshajk is on a distinguished road
    Join Date
    Feb 2019
    Posts
    7
    Points
    120
    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.
    Last edited by harshajk; Jan 23rd, 2020 at 05:20 AM.

  7. #7
    Advanced Advanced UC_wrangler will become famous soon enough
    Join Date
    Jun 2019
    Posts
    101
    Points
    2105
    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.

+ Reply to Thread

Tags for this Thread

Disclaimer

All content and materials on this site are provided “as is“. Infineon makes no warranties or representations with regard to this content and these materials of any kind, whether express or implied, including without limitation, warranties or representations of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, whether express or implied, is granted by Infineon. Use of the information on this site may require a license from a third party, or a license from Infineon.


Infineon accepts no liability for the content and materials on this site being accurate, complete or up- to-date or for the contents of external links. Infineon distances itself expressly from the contents of the linked pages, over the structure of which Infineon has no control.


Content on this site may contain or be subject to specific guidelines or limitations on use. All postings and use of the content on this site are subject to the Usage Terms of the site; third parties using this content agree to abide by any limitations or guidelines and to comply with the Usage Terms of this site. Infineon reserves the right to make corrections, deletions, modifications, enhancements, improvements and other changes to the content and materials, its products, programs and services at any time or to move or discontinue any content, products, programs, or services without notice.