• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 98 subscribers
  • Views 669 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Exception on OMAPL138

Marc48067
Expert 2000 points
Other Parts Discussed in Thread: OMAPL138

Hello,

When I start a debug session with CCS4 the FIRST TIME after powering up the OMAPL138 Experimenter Kit, the C674x always gets an exception. The EXC_dispatcher in turn redirects processing to UTL_halt(). When I terminate the first debug session in CCS4 and start it again (without power cycling the board) everything works fine. As you can see in EFR an internal exception occurred. As you can see in IERR it was a ressource conflict. The code which caused the ressource conflict is shown on the left side of the screen dump. It is code of the BIOS int dispatcher.  

 

 The exception only occurs when I map the int dispatcher data and code into L1 RAM. The corresponding Linker command file is shown below. When I remove the lines which map the int dispatcher data and code to L1 RAM, there is no exception upon the first run after power up.

 

 

 What does ressource conflict mean? Why does it only occur when I map the int dispatcher to L1 RAM? Why does it only occurr the first time after powering up the board?

Thanks in advance

 

  • 0
    Expert 2000 points

    Additional Info:

    L2 is configured as 128k RAM and 128k Cache. L1P and L1D RAM are configured as 16k RAM and 16k Cache each.

  • 0 in reply to Marc48067
    Expert 2000 points

    Hi,

    I had a closer look at the problem. When I load the program to C674x memory after power up, the code of restore_isr() looks o.k. . When I do a "run to main" the code changes as shown below. So during DSP BIOS startup sequence something goes wrong and illegal code is written to restore_isr() which lies in L1 RAM. No "own" code has run yet!! When I continue launching the code from main the exception occurrs. When I do not continue launching after having run to main but instead load the program again, the original code of restore_isr() is loaded again. Then when running to main after the second load, no code change can be recognized. When I continue launching from main no exception occurrs.

    I think the mapping of the bios int dispatcher to L1 RAM like I did it (via linker command file) is not allowed.

  • 0 in reply to Marc48067
    Expert 2000 points

    I removed the lines in the linker command file which map BIOS int dispatcher code and data to L1 RAM. For now everything works fine. But how can I map BIOS int dispatcher code and data to L1 RAM in order to achieve maximum access speed without using cache?

    Thanks

  • 0 in reply to Marc48067
    TI__Expert 7250 points
    We’re closing out this old thread. If you feel there is more discussion on the topic, please feel free to "Reply."