• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 83 subscribers
  • Views 1034 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.

RTOS/TMS320F28335: Debugging issue

Anjali Narayan
Prodigy 160 points
Part Number: TMS320F28335

Tool/software: TI-RTOS

We are having a problem using the debugger with our application.  Here are some of the pertinent details about our application:

  1. The processor is a TMS320F28335.
  2. We have tried using the XDS100v2 and the XDS510LC debugger with similar results.
  3. We are using CCS IDE 6.1.0, BIOS ver 6.35.4.50 and XDC ver 3.25.4.88

We can initially get the debugger to connect and show it started at the beginning of main.

The debugger can step through code at the beginning of main just fine.

As soon as it hits BIOS_start() function the code seems to act funny and we can no longer debug properly.  If we pause the code it just stops, and we get no source available for the memory address it stops and doing assembly stepping just stays on that address.

When we place a breakpoint in a task or a HWI we know should be occurring regularly the breakpoint is never reached so it doesn’t appear BIOS ever starts up correctly or at least it never gets the tasks going and the HWI’s are not occurring.

The original developer does have a hex file that is created from what should be the same source code and that file runs correctly on the board.  When we build the hex file and just program that in the board it also does not run correctly so it could be something is not building correctly.  The hex files do not come out to the same size and a file compare shows they are not the same file.

Our theory is some kind of exception or stack over flow in a task might be happening, though we are uncertain about that.

There are some screen shots below that show the code initially connecting to the debugger and starting at main, stepping through the initial main C code and then reaching BIOS_start() and the code going off in the weeds for some reason.

Hopefully someone has some suggestions to try that might help us get this working properly. Thank you.

 

 

 

  • 0
    TI__Guru 50595 points
    Hello,

    Do no breakpoints in tasks or Hwis get hit at all? The location that the code jumped to (at address 0x3ff9fa) is the illegal instruction handler in boot ROM. Are you able to step into BIOS_start() at all to get an idea of where it's happening?

    processors.wiki.ti.com/.../Interrupt_FAQ_for_C2000

    Whitney
  • 0 in reply to Whitney Dewey
    Prodigy 160 points

    Hi Whitney,

    No, the breakpoints are never hit. During debug, in ROV, under Task, the mode is 'invalid mode' and I'm not sure what caused that. Please refer the screenshots. Thank you.

  • 0 in reply to Anjali Narayan
    Intellectual 770 points

    Anjali,

    A few questions:

    1. Where was the PC when you paused and took those ROV shots above with "Invalid mode" shown? I assume that was right after the exception where BIOS exited.

    2. Have you tried adding 50% stack size to each Task stack (one at a time) and rebuilding/running to see if that makes a difference?

    3. How many functions do you have in Idle? Idle has its own stack, so include that in your "more stack" exercise above.

    4. If you set a breakpoint in the prologue (before the while loop) of the highest Pri Task (sys_monitor_...) (which should run first right after BIOS_start() ), you are saying you NEVER get to that breakpoint?

    5. When you single step into BIOS_start() (not step over), is there any indication of WHICH instruction is executing when the exception is thrown? The address 0x3F_FFC0 is the beginning of the boot rom vector table. This is enabled if VMAP=1, disabled if ENPIE = 0. Not sure if that has any bearing. But the address indicated in the error is "0xFFFF_FFFF_FFFF_FFC0" which is WAY out side of this memory map.

    It is odd. I am racking my brain to figure out what might cause an exception at the beginning of BIOS_start() prior to running any Tasks. It almost smells like a linker.cmd file problem. The tasks and stacks are in L4 and L6 SARAM, so no indication of problem there.

  • 0 in reply to Eric Wilbur
    TI__Guru* 96960 points
    Do any of the calls in main() directly change the vector table? If they do, are they using the Hwi module in TI-RTOS or directly tweaking the vector table via a driverlib call (or some other method)?

    Todd