• State
  • Locked Locked
  • Replies 10 replies
  • Subscribers 30 subscribers
  • Views 342 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

TMS570LS3137-EP: TMS570LS3137 - Safety library implementation - Prefetch abort exception when power cycling the board

RM44L920: Prefetch abort exception when power cycling the board

Ilija Cakovic
Prodigy 100 points
Part Number: RM44L920
Other Parts Discussed in Thread: HALCOGEN

Tool/software:

Hello,

I’m encountering the same issue described in this post , where a prefetch abort exception occurs when power cycling the board after implementing the SafeTI Diagnostic Library (SDL).

I’ve implemented the sys_startup exactly as  in the SDL demo application, and while the system works well with other reset types (e.g., debug, swrst, cpu), the prefetch abort only occurs during a power cycle. I’ve reviewed the linked post but couldn’t find a specific solution that applies to my setup.

Here are the register values I captured during debugging.

However, I’m unable to pinpoint the cause of the prefetch abort since I can’t view the code at the specified address in the disassembly. Any guidance on how to proceed or further investigate this issue would be helpful.

Are there any specific changes or checks needed in the sys_startup code or memory initialization when dealing with power cycling? Any insights or suggestions would be greatly appreciated!

Regards,

Ilija

  • 0
    TI__Guru 62590 points

    Hi Ilija,

    I don't have any about exact root cause for this issue.

    Ilija Cakovic said:
    I’ve implemented the sys_startup exactly as  in the SDL demo application,

    Can you please explain about the changes you made in detailed?

    So that i want to do same changes and want to reproduce the issue on my board for further debugging of this issue.

    --
    Thanks & regards,
    Jagadish.

  • 0 in reply to jagadish gundavarapu
    Prodigy 100 points

    Hi,

    Here is my sys_startup.c file, I compared it with one from SDL Demo but couldn't identify any differences that might be causing the problem.

    sys_startup.c.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    /** @file sys_startup.c
    * @brief Startup Source File
    * @date 11-Dec-2018
    * @version 04.07.01
    *
    * This file contains:
    * - Include Files
    * - Type Definitions
    * - External Functions
    * - VIM RAM Setup
    * - Startup Routine
    * .
    * which are relevant for the Startup.
    */
    /*
    * Copyright (C) 2009-2018 Texas Instruments Incorporated - www.ti.com
    *
    *
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Thanks & regards,

    Ilija

  • 0 in reply to Ilija Cakovic
    Prodigy 100 points

    Hi Jagadish,

    Have you made any progress with the issue?

    I wanted to add something I discovered—there’s an ESM Group 2 error visible in the Esm_Stat2 register with a value of 0x01000000. According to the TRM, this corresponds to a MibSPI5 RAM parity error.

    My concern is why this error is being triggered when I haven’t included MibSPI5 in my HalCoGen project.

    Thanks & regards,

    Ilija

  • 0 in reply to Ilija Cakovic
    TI__Guru 62590 points

    Hi Ilija,

    Ilija Cakovic said:
    I wanted to add something I discovered—there’s an ESM Group 2 error visible in the Esm_Stat2 register with a value of 0x01000000. According to the TRM, this corresponds to a MibSPI5 RAM parity error.

    Are you sure about this?

    Channel 24 in the ESM group 2 is Windowed Watchdog Violation:

    --
    Thanks & regards,
    Jagadish.

  • 0 in reply to jagadish gundavarapu
    Prodigy 100 points

    Hi,

    You're right! I went back and checked the documentation, and you are correct, I was actually looking at Group 1.Thank you for catching that!

    Do you have any idea why this windowed watchdog violation is occurring?

    Also, regarding the prefetch entry issue that was original question, have you found anything new that can help in resolving the issue ?

  • 0 in reply to Ilija Cakovic
    Prodigy 100 points

    Hi Jagadish,

    I wanted to kindly follow up on the original issue (prefetch abort). It's been some time, and I haven't received a response yet. I would greatly appreciate any update or insight you can provide.

    Is there any progress on this matter?

    Thanks & regards,

    Ilija

  • 0 in reply to Ilija Cakovic
    TI__Guru 62590 points

    Hi Ilija,

    Apologies for the delay in late response, i was stuck with other issues.

    Ilija Cakovic said:
    Do you have any idea why this windowed watchdog violation is occurring?

    This watchdog violation would occur if we failed to reset the watchdog within the configured time.

    For example, if you verify below code

    Here we are configuring Watchdog with 4095 counts right,

    That means expiration time will be as below:

    That means we should reset the watchdog before this expiration will happen using dwdReset() function, otherwise watchdog violation ESM flag will get SET.

    I think this is not related to your prefetch error, this will can be occurred if our code not executing main loop and maybe it stuck at somewhere else.

    Regarding prefetch error i am suggesting you refer below exception troubleshooting document.

    (+) [FAQ] TMS570LC4357: Troubleshooting the Abort Exceptions on Hercules Devices - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

    Using this you can find out the address where prefetch error occurring. So, please refer it once and debug project in according to it.

    --
    Thanks & regards,
    Jagadish.

  • 0 in reply to jagadish gundavarapu
    Prodigy 100 points

    Hi Jagedish,

    Thank you for your response.

    Regarding the prefetch abort issue, I have followed the steps outlined in the post for troubleshooting abort exceptions during debugging. As I mentioned in my original post, I’m unable to pinpoint which instruction is causing the prefetch abort. When I check the CP15_INSTRUCTION_FAULT_ADDRESS register, it shows 0x7B86CD9A, but I can't read the values at this address in the disassembly view.

    I just discovered that the issue appears to be related to the SRAM self-test, which seems to be causing the problem.

    When I remove SL_SelfTestSRAM() function there is no error.

    Could you provide any further guidance on how to proceed in this situation?

    Thanks & regards,

    Ilija

  • 0 in reply to Ilija Cakovic
    TI__Guru 62590 points

    Hi Ilija,

    My sincere apologies for the late response.

    Are you still stuck with this issue?

    --
    Thanks & regards,
    Jagadish.

  • 0 in reply to jagadish gundavarapu
    Prodigy 100 points

    Hi Jagadish,

    I was able to resolve the issue on my own.

    Thanks & regards,

    Ilija