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

Strange error BIOS 5.41, UTL_halt

jonas.sjoholm
Prodigy 120 points
Other Parts Discussed in Thread: OMAP-L138

Hello,

I need help with a error I get. It appears when I move the section (.bios) to IRAM from DDR. I can run the code if I use the "run to line" fuction without problem (through the hole code). But when I push the "play" button and then "halt" it stops in UTL_halt. It feels like a speed problem but should not IRAM has to be faster than DDR?

I am running on a OMAP-L138 experiment kit (from LogicPD) with BIOS 5.41, and the built-in emulator XDS100v1 on a computer running on Windows 7.

The code I am running is a modification of the audio example for the experiment kit.

I really would appreciate help

 

//Jonas

  • 0
    TI__Mastermind 20805 points

    Hi Jonas  --

    Which version of CCS are you using? 

    If you are using CCSv3, you should be able to open the "Tools->DSP/BIOS->Message Log" tool and look at the "System Log details" and you should see a string summarizing the error.  

    If you are using CCSv4, you should open the Tools->ROV tools and navigate to LOG object and then review the log buffers where you will see similar message.

    This should give some info about the error.  If that doesn't help, you can also place breakpoint on 'SYS_abort' function and look at stack backtrace (or B3 register) to see who called it.

    Some background.

    Code usually reached 'UTL_halt()' via a call to UTL_abort() (which is the default SYS_abort() handler).  You can replace the default abort handler with another function via a configuration parameter in SYS manager.  BIOS plugs 'UTL_abort()'  and 'UTL_error()' by default.  We provide the source code for these UTL functions in ti/bios/src/misc folder in your installation.  

    Regards,
    -Karl-

  • 0 in reply to Karl Wechsler
    Prodigy 120 points

    Hello,

    Thank you for the fast replay!

     

    I am using CCSv4, and yes I have been looking at ROV under LOG where I can find this

    ,1276,31956325571,EXC_exceptionHandler: EFR=0x2
    ,1277,31956325707,  NRP=0x2710
    ,1278,31956325735,  mode=supervisor
    ,1279,31956325814,Internal exception: IERR=0x1
    ,1280,31956325841,  Instruction fetch exception
    ,1281,31956326051,SYS abort called with message 'Run-time exception detected, aborting ...'

     

    When I set a breakpoint at SYS_abort() in stack I only see that fuction. In B3 register i get 0x118222BC where this is C$RL24 (what is this?)

    //Jonas

  • 0 in reply to jonas.sjoholm
    TI__Mastermind 20805 points

    Jonas --

    It appears that your code is jumping to invalid code or some other serious issue.   Can you check your stacks at the time of this failure?   In CCSv3, use Kernel/Object View tool.  In CCSv4, use 'ROV' tool.  Check the task stacks and make sure that they haven't overflowed.   The 'NRP' should point at/near the instruction that caused the exception.  You can put a breakpoint on 'hwi1' (the NMI vector) and catch the exception at the point it occurs and look at registers to see if you have any clues.  'B3' is useful since it contains return address of functions and might point to recent function that was called right before the failure.

    Can you run basic BIOS examples on this board?   This could be caused by any number of things, like bad memory or invalid EMIF setup.  Or by software problems like jump to bad address via a bogus function pointer.

    Regards,
    -Karl-

  • 0 in reply to Karl Wechsler
    Prodigy 120 points

    Karl

    In ROV under TSK I can find this

    TSK_idle,   0x1183d184  ,Running,0,0,0,,  0x1183c530,                                   1024,  392
    codecTask,0x1183d1e4  ,Blocked,5,35,0, SEM: 0xc3000304,0x11837ad0,  8192,  1148

    When I look at adress 0x11837ad0 (stack for my codecTask) i find this

    0x11837AD0:   BEBEBEBE     [!A2]  STB.D2T2      B29,*+B15[16062]
    0x11837AD4:   BEBEBEBE     [!A2]  STB.D2T2      B29,*+B15[16062]
    0x11837AD8:   BEBEBEBE     [!A2]  STB.D2T2      B29,*+B15[16062]
    0x11837ADC:   BEBEBEBE     [!A2]  STB.D2T2      B29,*+B15[16062]
    0x11837AE0:   BEBEBEBE     [!A2]  STB.D2T2      B29,*+B15[16062]
    0x11837AE4:   BEBEBEBE     [!A2]  STB.D2T2      B29,*+B15[16062]
    0x11837AE8:   BEBEBEBE     [!A2]  STB.D2T2      B29,*+B15[16062]
    0x11837AEC:   BEBEBEBE     [!A2]  STB.D2T2      B29,*+B15[16062]
    0x11837AF0:   BEBEBEBE     [!A2]  STB.D2T2      B29,*+B15[16062]
    0x11837AF4:   BEBEBEBE     [!A2]  STB.D2T2      B29,*+B15[16062]
    0x11837AF8:   BEBEBEBE     [!A2]  STB.D2T2      B29,*+B15[16062]
    0x11837AFC:   BEBEBEBE     [!A2]  STB.D2T2      B29,*+B15[16062]

    ....

    This is a picture of what I see when I have put a breakpoint at hwi1.

    I can run basic BIOS examples on this board, I can even run this code if i put the BIOS section in DDR memory instead if IRAM, but then the CPU load is at about 90% without any processing on the signal.

    Hope this will help you help me!

    //Jonas

  • 0 in reply to jonas.sjoholm
    TI__Mastermind 20805 points

    B3 should contain the return address of the last successful function call.   If you open dissassembly  window at B3, you should see some code and a branch/call to the code that may be causing the problem.

    NRP is the NMI return pointer and will contain the address of the code that ultimately generated the exception.  If you are executing "out in the weeds", you might execute a bunch of code before you actually generate the exception.

    How are you managing the CACHE?   The IRAM is shared between code/data and CACHE.  You can configure it to be cache or RAM.  You need to be careful that you don't have cache and RAM in same chunk of IRAM.

    If you have code in DDR, then you should make sure that you configure the 'MAR' registers to enable the DDR to be cached.  You can do this via the 'GBL' manager in the config tool.

    Regards,
    -Karl-

  • 0 in reply to Karl Wechsler
    Prodigy 120 points

    I have now got the code working. The thing I did was changing a Int32 pointer to a Int16 pointer and then i worked, don´t know why?

    About the CACHE I have L1P ,L1D and a allso 32k from L2 as CACHE. How do you know that RAM and CACHE is not in same chunk of IRAM?

    I have tried making my own sections in IRAM where I have put important functions that runs often, but I haven´t seen any improvement in speed actually sometimes the speed has decreased, why is that? Has it something to do with caching from L2 memory?

    The code is built by taking one sample at a time (I have seen that this is much slower than with a taking more samples at a time, when I have tested with a loopthrough code example). Do you suggest that I move some of the prebuilt pspdrivers into L2 or even L1 memory (edma, mcasp,...)? The code is made from the psp audio example where I have just made som small modifications (changed buffer length to 2, one left and one right,...).

     

    Kind Regards,

    Jonas

  • 0 in reply to jonas.sjoholm
    TI__Mastermind 20805 points

    Jonas Sj��holm said:

    I have now got the code working. The thing I did was changing a Int32 pointer to a Int16 pointer and then i worked, don´t know why?

    My guess is that you were stepping off end of an array.  The size of a pointer affects how 'ptr++' works.  If your look is expecting 16-bit values, you were probably iterating over an array boundary and trashing some memory.

    Jonas Sj��holm said:

    About the CACHE I have L1P ,L1D and a allso 32k from L2 as CACHE. How do you know that RAM and CACHE is not in same chunk of IRAM?

    My guess is that you were stepping off end of an array.  The size of a pointer affects how 'ptr++' works.  If your look is expecting 16-bit values, you were probably iterating over an array boundary and trashing some memory.

    If you use the BIOS configuration tool to specify memory, then we take care to make sure that the IRAM shrinks as you increase the size of the CACHE.  So the 2 chunks of memory will not overlap.  If you are setting the size of the cache at runtime, then you have to be careful since you can force cache size that conflicts with your RAM setting.  If you don't set cache sizes at runtime with BCACHE, you should be OK.

    Jonas Sj��holm said:

    I have tried making my own sections in IRAM where I have put important functions that runs often, but I haven´t seen any improvement in speed actually sometimes the speed has decreased, why is that? Has it something to do with caching from L2 memory?

    The code is built by taking one sample at a time (I have seen that this is much slower than with a taking more samples at a time, when I have tested with a loopthrough code example). Do you suggest that I move some of the prebuilt pspdrivers into L2 or even L1 memory (edma, mcasp,...)? The code is made from the psp audio example where I have just made som small modifications (changed buffer length to 2, one left and one right,...).

    It is best to work with buffers of many samples.  Smaller buffers mean more context switches between driver and your processing.   You should make buffers as big as you can tolerate.   Bigger buffers mean more latency, but in many cases this is OK.   There's a tradeoff here between latency and overhead. Smaller buffers will have lower latency but will require more task switches, etc.     It's very application specific what the right numbers are.

    I would recommend setting L2 cache size to max, and placing code and data in external memory and see if that meets your goals.  Let the chip and the cache do the work for you.  If performance isn't good enough, you can carefully place code and data in on-chip memory if necessary.