C6678 Core file analysis

Nikhil

I do not use a utility that analyzes core dump and associates it with source code (Is this what you ask for?).  There are other methods to debug crashing

Can you describe your application a little bit more –

1. Do you have CCS connected to the EVM?
2. Can you print on the consol?
3. Can you put breakpoint and see where you crash?
4. How does the map file looks like?  Do you use RTSC platform or you use linker command?

Please elaborate a little more

Ran

Nikhil,

You can continuously capture C66x core trace to Embedded Trace Buffer (ETB) in a circular buffer fashion and stop the capture of trace to the ETB exactly on the occurrence of a C66x exception (either internal or external exception). The trace captured in the ETB can be post processed and back-tracing to the root cause of the exception can be done. The following is the procedure to do the same in CCSv5.5 environment:

1) Load App SW (which is crashing) on core0 of C6678.

2) Before running the App SW, setup C66x core trace on core0:

- Go to Tools --> Hardware Trace Analyzer --> PC Trace

- A Hardware Trace Analysis Configuration dialog box pops up. Please, click on Advanced Settings

- Inside Advanced Properties settings, add a new trace trigger. The below snapshot shows the required settings for this new trace trigger:

- Click Ok, then on clicking apply, one can see Trace Viewer - C66x_0 tab open up.

3) Run the App SW to completion, either halt inside the C66x_0 exception handler or halt after exiting the application.

4) The Trace Viewer - C66x_0 tab will have a trace of C66x instructions (PC + timing information), backwards exactly from the point were the C66x exception was triggered. The number of back trace samples is limited to the size of the ETB (which is 4 KB). This back trace data can be used to get to the root cause of the exception.

For the case where multiple cores C66x cores are executing an application, without modifying the App SW, there is no straight forward way to communicate the exception taken on one core to all the other cores. Hence, it is not easy to generate the required back trace information on all the cores, on the event of a particular core taking an exception. If modifying the App SW is an option here, then C6678 provides certain CIC interrupts which can be broadcast to all the 8 cores. Therefore, inside the exception handler of a particular core, the CIC can be configured to generate these events to all the other cores. These events can be used on the other cores to stop trace capture to ETB. Each of 8 cores have their own ETB for capturing C66x core trace.

As another option, you can enable global breakpoints to halt all the cores on the event of an exception being taken by a particular core. Please, group all the 8 cores and right click on the group to enable global breakpoints, as shown in the snapshot below:

After enabling global breakpoints, on the C66x core which is taking the exception, put a breakpoint on the first instruction of the exception handler. Once the breakpoint inside the exception handler is hit, all the other cores will also be halted immediately. In this way the current state of all the cores can be determined on the event of an exception on a particular core.

I hope this helps.  

Hi Ran,

Yes I am looking at a mechanism/ utility to associate the core file to the source code (executable). 

I am using the Advantech card : http://www.advantech.com/products/DSPA-8901/mod_E0C0895C-497A-4BCF-B745-98DE52ED952A.aspx. This card has 20 Shannon DSPs on it. At this stage I do not have the Black hawk Emulator plugged to the Advantech card. 

Regards,

Nikhil

Hi Karthik,

Assuming I am able to connect the Blackhawk Emulator to the Advantech card, I believe I will be able to try what you have mentioned above,  Is that correct ?

Regards,

Nikhil