• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 99 subscribers
  • Views 1323 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.

TMS320C6742: No source available for "0x713d4e"

ikon
Genius 5355 points

Part Number: TMS320C6742

Hi Support,

My customer is developing the firmware on TMS320C6742 and encounter an issue. 

He is using emulator XDS200 and CCS 6.2.0.00050 to test his firmware on the custom board.

When stepping to debug his code after board power up, the firmware was running well.

But if run it continuously after board power up, it will stuck at address 0x713d4e and report the error No source available for "0x713d4e".

But 0x713d4e is in the address of DSP L2 ROM, which stores the factory boot loader.

Any idea why it could happen?

Thanks.

  • 0
    TI__Guru 65405 points
    Hi Ikon,

    I've forwarded this to the c67x debugging experts. Their feedback should be posted here.

    BR
    Tsvetolin Shulev
  • 0
    TI__Guru* 84110 points
    Ikon,

    "No source available" just means that the debugger cannot show you source code. You can still debug in the assembly window, if you want to do that.

    In almost all cases, this means the processor is in a location it should not be, it is not is a part of your program. You have confirmed this by finding that the location is in L2 ROM.

    This can be a very difficult problem to debug. The easiest and first thing to look for is stack overflow. Recommend to your customer that they try increasing the size of the stack or check for overflow of the stack in some way.

    Regards,
    RandyP
  • 0
    TI__Guru** 116870 points
    The device should execute bootROM code only after power on reset so there is some code in the firmware that seems to be pushing the core Program counter into BOOTROM or may be reseting the DSP core.

    If they can narrow down what part of causes this behavior, then they may be able add some delays in that section to see if this helps. The delays are just a workaround, and will need further analysis to understand the core to root cause it. One other thing to check is if the stack is getting corrupted during the continuous mode operation.

    Regards,
    Rahul
  • 0 in reply to Rahul Prabhu
    Genius 5355 points
    Hi Rahul,
    Here are the findings.
    1. Compiled the project and generated a bootable image. If I programmed this image into the NAND flash on the board, then I would encounter the problem reported. If the NAND flash is blank, the issue never happens.
    2. Only see this issue when I first time run the emulation after power-up. If I terminate the session when I encounter this issue and reenter the debugging again without recycling the power, then the program will run normally. But if I power off and on the board, the problem comes again the first time I start the emulation.
    Thanks.