• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 98 subscribers
  • Views 514 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.

Running IPC example ex02_messageq in the debugger

Keith Lankford
Prodigy 10 points

The processor is a Jacinto6 and I'm tying get IPC working on an M4 core. IPC_3_23_01_03, bios_6_37_03_30, xdctools_2_25_06_96.

We can load/run the example project from QNX on the A15 and it works.

It was recommended to us to use that example as a base project for our application.

I added a BSP/Starterware I2C driver to the example and it no longer runs.

In trying to debug that I found that I could not even load the original project into the debugger (CCS Version: 5.5.0.00077).

I've tried loading it directly, and also tried using the generated GEL script the console output is the same:

Cortex_M4_IPU1_C0: Breakpoint Manager: Retrying with a AET breakpoint

Cortex_M4_IPU1_C0: Trouble Setting Breakpoint with the Action "Terminate Program Execution" at 0x16b64: (Error -1066 @ 0x16B64) Unable to set/clear requested breakpoint. Verify that the breakpoint address is in valid memory. (Emulation package 5.1.600.0)

It crashes when executed.

I don't know why the I2C driver (that works on other project) kills IPC, but being able to debug an IPC application seems like a good starting point.

Thanks!

Keith

  • 0
    TI__Genius 12025 points

    Keith,

    When using QNX, you cannot use CCS to directly load and run the M4 processor. You must use QNX to load and run the M4. Once the M4 is up and running, you can use CCS to "attach" to the running M4. Once attached, you have full debug capabilities.

    Here are some items to consider. Make sure that your CCS debug configuration is not running any GEL functions when you attach. Edit your debug configuration, select the processor and make sure the gel script entry is empty.

    You will want to load symbols in CCS. Use the same executable that you are running. However, if you strip your executable, then you should load symbols from the executable that was not stripped.

    If you are running on both M4 cores (i.e. you are using SYS/BIOS in SMP mode), then you should connect to both cores in CCS. Be mindful that the SYS/BIOS scheduler can migrate a task from core to core. You might have to check both cores to find your running task.

    The ROV tools is a great help. Look in the Tools menu.

    If your slave application crashes before you can attach CCS, one trick I use is to insert a spin loop in the slave executable before the crash. Add the following line at a point in your program which can be reached safely.

    { volatile int spin = 1; while (spin); }

    When you attach with CCS, you should see one of the cores spinning in this loop. Use the variable window to change the value of 'spin' to zero. Then single step a couple of instructions. You should see it leave the spin loop. Now you can run and let it crash in the debugger to see what happens.

    ~Ramsey