• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 2 answers
  • Subscribers 29 subscribers
  • Views 346 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.

RM57L843: SL_SelftTest_ Reserved Access DataAbort

Matthew Bevacqua
Prodigy 140 points
Part Number: RM57L843
Other Parts Discussed in Thread: HALCOGEN

I am trying to port the safety library v2.4.0 code to my custom board and CSS v8.3 project using HalcoGen v4.06.  I am stuck on making the reserved access memory tests work (eg SL_SelfTest_MemoryInterconnect(MEMINTRCNT_RESERVED_ACCESS) )  When I attempt to read the reserved memory location, I receive a DataAbort interrupt which stops the execution.  How can I set Halcogen or my project configuration to prevent this interrupt and allow the SL function to check the error on its own?  

One thing I did notice that seemed unusual is that when the dataabort interrupt occurs, I'm receiving a status of 0x00 which is listed as BG.  I'm not sure what BG stands for and, regardless, it looks like the SL_SelfTest_MemoryInterconnect function is expecting a fault code of 0x08.

Any help would be appreciated.  

Thank you

  • 0
    TI__Mastermind 49120 points

    Hello,

    The data abort generated by the self-test is intentional, and makes sure that the processor does indeed respond with an abort when an error is intentionally generated. The code execution does not stop, rather it starts executing the data abort handler and then returns back to executing the code that was being executed.

    Regards,

    Sunil

  • 0 in reply to Sunil Oak
    Prodigy 140 points

    Sunil,

    Thank you for the response.  I discovered that the HalcoGen project for the demo does not have the interrupt references enabled for _dabort when opened in version 4.07, but it is actually using an error handler to process the interrupt.  I sorted that out in my application and I am now left with the problem that my data fault status is a non masked Background Fault (0x00) and not the (0x08) that is expected.  The test memory location appears to be in an enabled region in my HalcoGen MPU configuration, so I'm not yet sure why that is happening.

    Matt

  • 0 in reply to Matthew Bevacqua
    TI__Mastermind 49120 points

    Matt,

    I see that the address used for this test on RM57x is 0x08080000U. This part has 512KB of CPU RAM, so this address would be outside of the available RAM. The MPU region for CPU RAM is also setup for a 512KB region size. So it is expected for this address to not fall within any defined region, thereby causing a background fault.

    Regards, Sunil

  • 0 in reply to Matthew Bevacqua
    TI__Guru** 114410 points

    Matt,

    That is correct the SL_SelfTest_MemoryInterconnect function reads the Data fault register on Cortex R and the status options are mentioned in the Cortex R TRM from ARM:

    I would check all the sub regions in MPU settings that you are using and the sub regions that are setup. Note sub regions can be over lapping and the higher region number setting over rides the lower sub region setting. If MPU settings are not defined correctly, the result can be a Background Data Abort. The need for MPU also depends on the mode of the CPU: Privileged or Non-Privileged. There are a couple of examples of why back ground fault can occur in the Cortex R TRM in the section  "Examples of using sub regions" and "background regions"

    Regards,

    Rahul