• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 99 subscribers
  • Views 1118 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.

DSP/BIOS scheduler strange behavior

Stan Sidorov
Expert 1985 points

Hi there,

I have 8 tasks in tcf-file, where 7 are defined by me and the last one is a system one (TSK_idle). So I am expecting to see the same names of these tasks in ROV. However, one of the task there always has different name. For example: sysevent - in tcf-file, but in ROV it is _CLK_run. Whatever I did in tcf-file, strange _CLK_run name always in the ROV. So why is that and how to fix this? The reason I am asking is I have unexpected hangs of the system and would like to make sure it is not DSP/BIOS itself.

Here is my setup:

CORE C5535

CCS 5.5.0.00077

DSP/BIOS 5.42.1.09

XDAIS 7.21.1.07

XDCtools 3 versions have installed 

3.25.4.88

3.25.3.72

3.24.7.73

Thanks

Stan

  • 0
    TI__Mastermind 32475 points
    Can you check your *.map file to see where the symbols are? Its possible that more than 1 symbol can have the same value...but in this case it does not sound right that one of the task would be at the _CLK_run symbol. What do you see in ROV when you get to main() before running your program?
  • 0 in reply to judahvang
    Expert 1985 points

    Hi judahvang, thanks for the quick reply.

    To make myself clear. Here is a my tcf-file:

    So I launched a debugger and before running the program I made a snapshot of the ROV:

    Here you can see weird _CLK_run instead of alarm.

    Than I looked into the map-file and found _CLK_run appears in two places with the same location:

    1.

    2.

    I also found alarm task which also has the same location:

    Any ideas why is that?

    Thanks.

    Stan

  • 0 in reply to Stan Sidorov
    TI__Mastermind 32475 points
    So looks like both symbols have the same value. This could be possible if one is in "code" space and the other is in "data" space.
    I don't think this is really your problem. ROV when it takes that address and parses the symbol table is finding the wrong symbol first and thinks that is the task name but this does not affect your runtime execution.

    Judah
  • 0 in reply to judahvang
    Expert 1985 points

    judahvang, thanks.

    It makes sense. However, it is still quite strange because 0x0000670e(word) -alarm but 0x0000670e(byte) -  _CLK_run. Anyway, I am relying on your reply and will not dig towards this direction.

    So but I still have a problem - it is total crash of the system even debugger displays red message in the console. I would think it is WatchDog timer resets the core, but it is not and the core hangs somewhere and the only way to get it back is to make HW reset. I am thinking over buying XDS560v2 and believe that tracing feature should help to debug the problem. Any comments and suggestions will be really appreciated. 

    Thank you

    Stan

  • 0 in reply to Stan Sidorov
    TI__Mastermind 32475 points
    What debugger or debugging tools are you using currently? Sounds like you are losing the emulation?
    So you have no ideas where your program counter is when it fails?
    The C5535 is not a device I'm really up to speed with.
  • 0 in reply to judahvang
    Expert 1985 points
    XDS100v2.
    The crash happens even without the emulation when program runs from image. I think it is not the matter of the core itself. I am still blaming DSP/BIOS for this crash and trying to find the ways to resolve that. Since there is a lack of the debugging tools in DSP/BIOS I am looking towards XDS560v2 . However, all tips and suggestions are more than welcome.

    Thank you

    Stan
  • 0 in reply to Stan Sidorov
    TI__Mastermind 32475 points
    I'm not sure how a different emulator will help you here. I would try to get the debugging tools working with the current emulator and instrumenting the code to see if you can pin point where its gone bad.
  • 0 in reply to judahvang
    Expert 1985 points
    Thanks judahvang, will do.
  • 0 in reply to judahvang
    Expert 1985 points
    This issue was resolved. It was pointer to pointer problem.