• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 2 answers
  • Subscribers 32 subscribers
  • Views 817 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.

CCS/AWR1642BOOST: Consistently getting exception thrown on boot

Rob Bacon
Prodigy 30 points
Part Number: AWR1642BOOST
Other Parts Discussed in Thread: UNIFLASH, AWR1642, MMWAVE-SDK

Tool/software: Code Composer Studio

Hi,

I'm attempting to modify the mmw demo project from version 2.0.0.4 of the mmwave_sdk (I couldn't get the demo from the LTS version 2.1.0.4 to work), and am having trouble debugging my code.

I've flashed the xwr16xx_ccsdebug.bin binary using the cloud uniflash tool.

The first run after a hard reset leaves the instructon pointer at the first line of main, however breakpoints don't seem to be working. After this any further attempts to debug result in a thrown exception as reported in the console:

Exception occurred in ThreadType_Task.
Task handle: 0x800cef8.
Task stack base: 0x800b000.
Task stack size: 0x800.
R0 = 0x00000000  R8  = 0xffffffff
R1 = 0x00000000  R9  = 0xffffffff
R2 = 0x00000000  R10 = 0xffffffff
R3 = 0x00000000  R11 = 0xffffffff
R4 = 0x00000000  R12 = 0x0000215d
R5 = 0x0000a6d8  SP(R13) = 0x0800b7d0
R6 = 0xffffffff  LR(R14) = 0x00007e6c
R7 = 0xffffffff  PC(R15) = 0x00006b7c
PSR = 0x400c019f
DFSR = 0x00000000  IFSR = 0x00000000
DFAR = 0x00000000  IFAR = 0x00000000
ti.sysbios.family.arm.exc.Exception: line 209: E_undefinedInstruction: pc = 0x00006b7c, lr = 0x00007e6c.
xdc.runtime.Error.raise: terminating execution

If I restart the processor then I get the same error, however if I reset the CPU and then resume then the code executes but once again no breakpoints work.

This behaviour is intermittent, occasionally I'll be in a situation where the debugging works as expected (though often it requries two clicks on the debug button to execute), but a few code changes later and we're back in the non-working situation again.

I'm using CCSv9.

Any thoughts?

Rob

  • 0
    TI__Guru 68160 points
    Hi Rob,
    When you do the power cycle after flashing the ccsdebug.bin, CCS connect may show you some opcode which means that it's not able to map the source code for CCSDebug.bin binary.
    At this point you need to do the core reset (MSS/DSS) and then load the debug image via CCS to these cores. Then only CCS will map the source code of image which is loaded.
    Other point to note that mmw demo application is optimized so with CCS you may not able to put the breakpoint at the exact line of source file, in this case better to put the breakpoint in the CCS disassembly window (looking to specific function or address).

    Do you see above mentioned exception from the default mmw demo application or with the modified application only? As error says it's hitting undefined-instruction while execution, you need to check this error at your end as just putting a breakpoint won't cause this error. Check for stack overflow, null-pointer error or backtrace based on PC/LR provided in the exception error message.


    Regards,
    Jitendra
  • 0 in reply to Jitendra Gupta
    Prodigy 30 points

    Hi Jitendra,

    When I flashed the ccsdebug.bin I placed the board into flash program mode using the jumpers, turned the board on, flashed the image using Uniflash, turned the board off, then replaced the jumpers into functional mode. Only then did I load CCS and try debugging, so I think that CCS should be OK with the source code mapping at this point?

    I've turned off optimizations in my modified application so this shouldn't be an issue.

    The error occurs in both my application and the mmw demo.

    The PC instruction is in the function _c_int00, on line 289 of boot.asm, whilst the LR is pointing at code in the Idle_run function of Idle.c. This made me think that the error might actually be from the previous execution (I'm not very experienced on debugging embedded systems!), which in turn made me try a CPU reset followed by a restart and this then stopped the exception from occuring.

    I then added a breakpoint in the debug perspective (all the previous ones had been added in the edit perspective) and this worked fine and I noticed that the two breakpoints now look different in the breakpoints list as shown in the screenshot below:

    This now seems to let me work around the problem ,but I would like to know if my conclusions are correct - in that I need to hard reset the CPU between debug sessions, and that breakpoints inserted in the edit perspective are different from those added in the debug perspective?

    Thanks,

    Rob

  • 0 in reply to Rob Bacon
    TI__Mastermind 22155 points
    Rob,

    What is the version of your AWR1642? Is it ES1.0/ES2.0?

    -Raghu
  • 0 in reply to Raghunandan Kamath
    Prodigy 30 points
    Hi Raghu,

    It's' an ES2.0 board.

    Rob
  • 0 in reply to Rob Bacon
    TI__Mastermind 22155 points
    Rob,
    All the procedure you have followed seems to be right and should work without any issues.

    Could you please erase the flash on the EVM and follow the same procedure you mentioned above to flash CCSDebug.bin . Then use the mmw demo application .
    Please use the MMWAVE-SDK version 2.1.0.4 for the AWR1642 ES2.0 device.

    Thanks,
    Raghu
  • 0 in reply to Jitendra Gupta
    Prodigy 120 points
    How do you do the core reset of MSS/DSS as mentioned here?
  • 0 in reply to Jason Wright1
    TI__Mastermind 22155 points
    Jason,
    You can do core reset of MSS/DSS from the CCS "SYSTEM RESET" .

    -Raghu