• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 52 subscribers
  • Views 2043 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.

Original question:

RTOS/CC2652R: Finding my MCU looping with an attitude in Error_policyMin(), can't easily see why? Help?

RTOS/CC2652R: Error_policyMin? How to find why I'm getting in this routine? I can't be the first to wonder how to track this down?

Marc Yaxley
Expert 1115 points

Part Number: CC2652R

Tool/software: TI-RTOS

I am getting stuck (about 30% of the time) on boot up in this routine (/home/marc/ti/xdctools_3_51_02_21_core/packages/xdc/runtime/Error.c)

Void Error_policyMin(Error_Block *eb, Types_ModuleId mod, CString file,   Int line, Error_Id id, IArg arg1, IArg arg2)

which is in the XDC/TiRTOS source code area.

The "*eb" is null, "mod" is 36, "file" is null, :"line" is 957,  "id" is 1048576, "arg1" is 3, "arg2" is 1

The question is how to use these numbers to find out what is going on?

I am using a debug settings kernel, CCS900, all updated and such.

This routine, can I be getting into it due to an exception?

There is no real data to help, a line number 957, but in what file?  an ID and couple of arg values

are also shown.  The *eb pointer is NULL and the "file" is NULL, so what gives?

Could someone at TI that knows this routine and XDC tools where the Error.c file is give me solid

advice on how to back track this to the root cause.  It doesn't always happen but seems to be when

I'm calculating my sine wave forms using floating point, but I can't really break point it to the spot

as it is inconsistent.  I loop about 500 times calc. sin() values and so on.

This is getting critical as I already wasted (well read, dug in and so on) the routine and some of

the XDC stuff but since ROV and the *eb is NULL can't really tell why I'm in the hang up again...

Please advise me what to look at or send you to help evaluate.  I am trying to stay out of the

CortexM assembly language and registers, that's why we have C language.  Somewhere there

is a TI Kernel function that is tripping up and getting me hung, but where?

The previous TI helper send me down some good roads but more wild goose chasing than

I had to since I was already doing most of what he suggested.  He missed the mark on what the

routine does and is telling the programmer when you wind up hung up in it...

Marc

  • 0
    TI__Guru 58425 points
    HI Marc,

    As I guess you have figured out, this routine is one of the available policy functions that is invoked when the kernel raises an error (search your .cfg file for "Error"). The idea is that you should have an error block to handle in this case, but these are rarely used due to memory footprints (almost all kernel APIs can take an error block if provided during creation/construction).

    In the end, it often boils down to the application experiencing an hardware exception of some sort. When you use ROV, did you by any chance look after hardware exceptions or did you simply inspect the "Error" module? Most information is gained trough the "Hwi" view where you can change to inspect the hardware exception (basic,raw, detailed, hardware exception, etc.), this is where I would recommend you to start looking. This can be more or less clear depending on the level of optimization you currently use.

    I would also recommend that you check your system stacks to see if these are intact when the crash occurs. You could use ROV and look at the "Task" view and check the peak values but you could also take the "base address" for the task from this view and check them using the memory browser, you should find "BEBEBEBE" padding bytes at the end of your stack range, if you do not, then it is likely you had an overflow.
  • 0 in reply to IUsedToBeARealPerson (M-W)
    Expert 1115 points

    Thanks, this helps a bit to context what those routines are there for.  I'll look into the HWI also to see

    if the source is there.  It always could be stack as one developes code and calls several functions

    deep (that have their own variables, stack based) it could over flow the stack at any minute of run

    time, even in lib's or math functions and create a hard to locate situtation.  I'll go down these paths

    you suggest.

    Your help has been great!

    Marc Y.