RTOS: Exception handling support for 6416 single core processor.

Hanumanth,

In a duplicate thread here, you mentioned 2 different part numbers. I assume C6416 is correct, but please clarify that before we continue too far on this.

CPU Exception handling, such as for invalid program/data accesses or invalid instruction codes, was not included in our DSP families until the upgrade from the C64x core in the C6416 to the C64x+ core in the C6455 (and later cores, such as C674x and C66x). So exception handling is not available for the C6416 devices.

Troubleshooting and debugging major exception events is difficult without that extra help, and even with the exception handling it can be hard to do. Methods of debugging vary depending on the nature of the failure, how often it occurs, how repeatable it is, how consistent it is, and so on.

Please describe the situation so we can give you debugging advice that is suited best for your failure situation.

Some ideas are:

1. After the failure happens and you get control of the device under emulation control, find the value of the Stack Pointer and look at the memory locations near the end of the stack (slightly higher addresses) to see if any values look like program-space addresses. One of these could be the the saved return address from a recent function call. You can look at other locations on the stack to see how they might compare with how the stack frame would be composed for various functions in your application to get an educated idea of where the program may have crashed.

2. A favorite tool for me is the creation of a circular buffer into which I save information regularly during the running of the application. A simple number from 1-10 might be used to indicate one of 10 different functions when it gets entered. Then some other values might be stored along with that to form a "struct" of values showing history. After the failure happens and you get control of the device under emulation control, find the pointer location within the circular buffer and determine what the most recent function was that executed before the failure. This may help locate a suitable place for a testing breakpoint.

3. Eventually, you will try to narrow down the location of the failure and set a breakpoint as close to that location as possible. If you can do that, and then single-step until something bad happens (like branching to invalid program space), then you will be closer to finding the source of your failure.

Regards,
RandyP

Hi,

Thanks for your quick reply.

Our application deployed on 6416 single core processor, DSP/BIOS v5.20.00,   i.e (bios_5_20_00_22, cgt_c6000_5.1.0). I had look on  BIOS/DSP User Guide, i didn't get significant  information on exception handling for 6416, pls share if you have any idea.

Thanks in advance.

Regards,

Hanumanth

Hi RandyP,

grateful to your in details explanation and suggestion,
Yes, My part number is C6416, thanks for clear confirming the exception handling unavailability on this C64x core in the C6416 .
Yes, We will look into the debugging possible ideas,
coming to your pointers, idea 1 and 3 for our application which is deployed on 6416 is completely customized, compacted in box, we can't connect JTAG and can't get control of the device under emulation control, we can't debug using break points method,

idea 2 : My point along with your idea is, since we can't connect JTAG and can't get control of the device under emulation control But every interval of time we can pullout the buffer(which is having function level or task level information) out of system module and using SRIO or ethernet, and get the last packet and check the value of each stage, will help us to point out the last task or function it came out of system module and hence we can somehow we can point out the root cause for the software crash .

Please let me know anymore suggestion,


thanks again,
Hanumanth