• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 379 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.

RM48L952: prefetchEntry during checkRAMUERRTest()

K De Coster
Intellectual 740 points
Part Number: RM48L952
Other Parts Discussed in Thread: HALCOGEN

Hello there,

I am using HALCoGen generated code for the RM48L952, I am not using interrupts (they are disabled via _disable_interrupts_(), vim is also configured to not generate interrupts.
To check for errors I check esmREG->SR1[0..2], esmREG->SSR2 and the core cp15 registers (datafault, instructionfault..).
I want to run checkRAMUERRTest() generated by HALCoGen periodically.

When running without debugger connected (after PORST) this works fine.
However when I connect via JTAG a prefetchEntry interrupt is called at the end of the checkRAMUERRTest function. If I then restart (nRST) and re-run the program no prefetchEntry interrupt is generated.
In the prefetchEntry i read out the cp15 registers.

_coreGetInstructionFault_() returns 0xd indicating permission
_coreGetInstructionFaultAddress_() returns 0xe3cfefc6.

Any help on where or how to look for the instruction fault would be welcome.
Is this related to the MPU or CPU mode (sys, user, ..)?

Best regards,,

Karel

  • 0
    TI__Guru**** 193226 points
    Hello Karel,

    It looks like the code is trying to access an unimplemented memory. The CCMR4 test required code execution without JTAG connected, but for SRAM and flash related test, the JTAG should not impact the test.

    Do you have breakpoints when you run the code? When JTAG is connected, when RUN option do you use, RUN (resume) or Free RUN?
  • 0 in reply to QJ Wang
    Intellectual 740 points
    Hey QJ,


    I am not performing the CCMR4 test.
    I am using GDB. I do have brakepoints set. I am performing checkRAMUERRTest() and checkRAMAddrParity() in _c_int00 before the call to main().
    Setting breakpoints or stepping (step/next) through the code or continue'ing (continue) does not seem to affect this.
  • 0 in reply to K De Coster
    TI__Guru**** 193226 points

    Hello,

    I just did the same test, didn't see any problem. I did checkRAMAddrParity() after pbist test.