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.

LAUNCHXL-CC2640R2: ti_sysbios_family_arm_m3_Hwi_excHandlerAsm__I called on stepping into some functions

Part Number: LAUNCHXL-CC2640R2
Other Parts Discussed in Thread: CC2640, SYSBIOS

OS-Linux(Ubuntu)
CCS Version: 10.2.0.00009
Device- CC2640

Hello, I downloaded the "empty" project from Resource Explorer and then added some C source files to implement LMS and low pass filter, which have been generated using MATLAB Coder for ARM M3 target. Upon building, the project builds successfully. Debug is also entered successfully. However, when I try to step in to some functions that are defined in other C source files, I get the following errors:

Cortex_M3_0: Can't Run Target CPU: (Error -2134 @ 0x0) Unable to control device execution state. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.3.0.00032)
Cortex_M3_0: Error: (Error -1170 @ 0x0) Unable to access the DAP. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.3.0.00032)
Cortex_M3_0: Unable to determine target status after 20 attempts
Cortex_M3_0: Failed to remove the debug state from the target before disconnecting. There may still be breakpoint op-codes embedded in program memory. It is recommended that you reset the emulator before you connect and reload your program before you continue debugging


I also tried disassembly and stepped through the assembly code. I noticed that a Hwi exception occurred when I tried to step into these functions.

This is what was getting called on trying to step into the function: ti_sysbios_family_arm_m3_Hwi_excHandlerAsm__I

Please see the screenshots below. Would appreciate some help on how to resolve this problem.

Thanks

Tushar

  • Hi Tushar,

    Could you please confirm you manage to properly step in the unmodified empty project?

    Could you please also verify if the following document helps? https://software-dl.ti.com/ccs/esd/documents/ccsv7_debugging_jtag_connectivity_issues.html

    Best  regards,

  • Hi Clement

    Yes, I am able to step into the unmodified project without any issues. It is only after adding the new source files that I am seeing this issue. 

    I tried something today - added some of the code from these functions directly into the main function and I was able to step through these lines but I encountered the problem inside a do-while loop now. 

    I went through the manual shared by you but the relevant recommendations weren't of any help to me. I did try reducing the JTAG clock speed from the 5.5MHz default to 3.3MHz and then to 1MHz but that did not help. 

    Thanks

    Tushar

  • Hi,

    This could be caused by an issue with the code (see here).

    I would recommend to identify the piece of code triggering the issue. It may be some code letting the device to go into sleep mode or forcing a device reset.

    Best regards,

  • Hi Clement

    In the C source file I was using some arrays of type double which had size of 1000.
    I notice that the errors (like unable to access DAP, Can't run target CPU and other errors as mentioned in first post) appear when I try to use these arrays.
    So I reduce the array size to 50 and then some arrays work fine but still some give error. Then finally I changed all array types from double to float and also reduce array size to 15, now the code is working fine.

    So, I want to know if there are any limitations in CC2640 on how big an array can be and can it handle double and float type arrays?

    Thank you,
    Tushar

  • Hi,

    Thank you for checking into this. It seems the issue is due to the code, not to the hardware (i.e. JTAG/cJTAG).

    I would recommend to root cause the issue (see below) and open a new thread to discuss it.

    Among others, maybe you should verify you are not running out of RAM (heap or stack).
    You could also verify the way the device represents the number is compatible with the way Matlab generates the code. For example, is the same endianness used, is the same floating point support used, etc. These can be verified in the project properties.

    I hope this will help,

    Best regards,