• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 560 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.

checkRAMECC causes hang when reading inserted double bit error

Matt Harding
Prodigy 220 points
Other Parts Discussed in Thread: HALCOGEN

Hello,

I'm using RM48 development board with CCS 6 and HalCoGen.

The application hangs in checkRAMECC() after it inserts a double bit error, then tries to read it, 

ramread = tcramA2bit;

Single stepping through the code, when I click to single step over this line, I see "No source available for "0x10" "

In the disassembly window, address 0x10 shows "Target failed to read 0x10 [ code = 0x1]"

When not single stepping, just running in debug mode, I see a similar message "No source available for "0x0c" "

In the disassembly window, address 0x0c shows "0000000c:   DFFFFFFF SVCLE           #16777215"

I'm lost as to what is causing this. Any assistance would be great!

Thanks,

Matt

  • 0
    TI__Expert 4580 points

    Hello:

    Can you share the CCS project showing this issue? I don't see any problems when running checkRAMECC API. The addresses you mention correspond to the prefetch and data abort vectors.

    Regards,

    Enrique

  • 0 in reply to Enrique Lizarraga
    Prodigy 220 points

    Hi Enrique,

    Sorry for such a delay in getting back to you.

    I put all relevant files together and they are attached. I have "Enable ESRAM ECC Check" un-checked in HalCoGen to get around the problem.

    I noticed another interesting behavior that may be related. I can load code and enter Debug. If I "Suspend" and "Restart", it will hang at address 0x4. If I then "Suspend" and "Restart" again, it will run normally.

    Also, if I load code as described above, allow it to run, then "Terminate" such that the application is still running, but I am no longer debugging, it will run normally. But then if I remove and re-apply power, the application will not run. And the ESM light is illuminated.

    So, there are 3 separate, but possibly related issues I'm having.

    1) checkRAMECC

    2) Hang at 0x4 after "Suspend" and "Restart"

    3) Application not running, ESM active, when removing and re-applying power.

    Thank you in advance!

    Matt3630.makefile_project_test1.zip

  • 0 in reply to Matt Harding
    TI__Expert 4580 points
    Hello:
    I verified your project and the only problem I found is you have the linker file disabled (excluded from build). Please unselect "Exclude from Build" option in sys_link.cmd file under source folder. After that you'll see the interrupt vectors correctly programmed. You can enable RAM ECC test again and it should run without problems.
    Regards,Enrique
  • 0 in reply to Enrique Lizarraga
    Prodigy 220 points

    Thanks for looking into it Enrique. I unselected "Exclude from Build" for sys_link.cmd in the source file (this was generated by HALCoGen). I selected "Exclude from Build" for sys_link.cmd in the upper level folder (This is one I was working on). It built fine. Loaded fine. But when running, it hangs up in

    void errata_PBIST_4(void)

    At the line

        *(volatile uint32 *)0xFFFF0400U = 0x0000000AU;

    It looks like a data abort occurs. I took a screen shot with register contents if that helps to diagnose! Thanks

  • 0 in reply to Matt Harding
    TI__Genius 14205 points
    Hi Matt,
    Your project works fine for me, with one change. I excluded the sys_link.cmd at top level and Enabled the one inside Source folder which is generated by HALCoGen.
    Looking at the Top level sys_link.cmd file, you have mapped Vector table to 0x00020000.. This cannot be done in Cortex-R4. The Vector Table must be at address 0. Please go back to HALCoGen Generated sys_link.cmd file, if needed you can add/Edit memory sections, but do not disturb the .intvecs section.
    Also, the HALCoGen startup file intentionally generates couple of data aborts, so if the vector table is messedup or not mapped to address 0, starup would fail.