Emulator partly/intermittently working with larger programs?

Tom,

Neither the emulator nor CCS require anything on the target code to performs its functions. 

However, check this thread that explains why CCS may not reach main() and how to disable this default setting.

The fact you are able to run the code at the second run is probably caused by malformed initialization routines, either from the GEL script or from the code itself, that expect values to be initialized - a reversed case of what is mentioned at this post.

Since your code is still working as it grows, I don't think it is experiencing what happened at this post/thread - a pretty catastrophic scenario, but nonetheless worth watching it. 

Hope this helps,

Rafael 

Hi Rafael,

Thanks for getting back to me!

I tried the first thing you mentioned in following the instructions listed below ( copied from the forum topic you linked to ).

"By default the CCS debugger will automatically run to your main() function after the code is loaded, therefore if anything in the initialization routine is preventing the device to reach it or maybe it is even resetting the device, the debugger will appear as "running forever".

If you want to disable the autorun to main, go to the menu Run --> Debug Configurations, select your configuration and select the tab Target. Then, scroll down until you find Auto Run Options (in newer versions you have to select Auto Run and Load Options) in the tree. Remove the main and de-select the checkboxes. Next time you load the code, it will be in the entry point _c_int00 and halted.

This will help to see where your code is losing control, and therefore you can start debugging from the very beginning of its execution."

When I do this, the code downloads and still "takes off" and runs.  Upon "Suspending" I get to what is shown in the attached picture.  From the address, it appears the code is running something in the DSP's ROM, and not going to the _c_int00 entry point.  Any ideas on what to look at next?

The reason I thought it was about the code size is that by removing a function ( that has previously worked for the last year or so ) the code size was reduced and the debugger/emulator would work correctly.  But now something else has changed and that doesn't even work.

The reason I didn't think it was something in my code, is that this is a problem even before my code starts running.

Also, something I haven't seen before in the previous version of CCS, but in the attached picture you might notice the Debug window shows "headset4_19pt2_DMA_I2C" which is a previous version of my code and NOT the current version ( or directory name ).  Opening up a file in the project, the "headset4_19pt2_DMA_I2C" ( not the correct directory ) name is listed before the file name, but when the edits are saved, they do change the file in the correct directory and file ( as I have verified using an external text editor ).  Any idea why this latest version of of CCS would get this messed up, and how I can fix it?

Please reply soon if possibly as I have a status call with my customer on Friday and I really need to get this working by then if at all possible.  I'll be working all night if I have to.

Thanks again,

Tom

Tom,

Given you are getting a previous version of the code when launching the debugger, I imagine you are using the green bug button, right? If so, I strongly suggest you to launch the debugger manually according to this post (copied below). This will guarantee that you are loading the correct code.

another thread said:

In this case, to try and pinpoint the exact place the problem is occurring, can you ask your customer to manually launch the debugger and connect to the core?

To do that, simply open the Target Configurations view (menu View --> Target Configurations), right-click on the .ccxml file and select Launch selected configuration. After the debugger launches, you can right-click on the core and select Connect. Once the core finishes executing its initialization GEL script, you can load the code by going to menu Run --> Load --> Load Program.

One of the possible reasons for the old code being loaded is shown in the first paragraph of this post (copied below).

yet another thread said:

By default the debug button performs several steps: find what is the Default (per workspace) or Active (per project) target configuration, create a Debug Configuration file (or use one created by a previous session), launch the debugger with the settings defined in this file, connect to the core compatible with the C project, load the code to the target (erasing flash if configured/necessary), run and halt at main() (or not run at all depending on the Debug Configuration file). These steps are performed in sequence and all may be done manually as you indicate in your post.

Given the Debug Configuration file can be out of sync at times, it can usually be removed as it gets re-generated with updated parameters. Check the section Debugger of the CCSv5 Troubleshooting page.

Hope this helps,

Rafael

Hi Rafael,

 It wasn’t a matter of opening the wrong files, as the editor, compiler, and debugger all operated on the correct files in the correct directories.  CCS just simply called the directory the wrong name, even though the files were in the correct directory with the correct name.  I believed I fixed it by simply right clicked on the name in the Project Explorer window and selected “Rename” to change the name.  Since then I haven’t seen the problem.

But anyway, that was NOT my main problem, and what is killing my project, and that I really need help with, is the code getting lost on booting before even running my code.

So I was able to extract the source code for the RTS library and copied the boot.asm file to my code base and started to debug the _c_int00 function.  I found the code would “get lost” when the “call _auto_init” function was executed and the code would not return.  So I copied the autoinit.asm file to my code base and have been trying to figure out what’s been going wrong with the _auto_init function.  I don’t have a clear answer as I can’t get breakpoints to work consistently in this assembly code, and as far as I can tell it appears to fail in a couple different locations in this code.  I’m attaching the autoinit.asm file for this discussion.  I can step through the “LOOP” from lines 118 through 153 and it appears the cinit table is getting read correctly.  But I believe the copying of the table ( on lines 150 and 151 ) sometimes gets lost and the processor gets lost, but I’m not sure as I can step through this and it appears to work, but when I Resume, with a Breakpoint on line 153, the code never breaks on line 153 and the processor gets lost.

 In the debugger, I did look at the 16 bit hex values of the cinit table ( that the above mentioned code is reading ) in the DSP and it does appear to have “Initialization Records” data as described on page 146 or TI’s SPRU281G document.

I’ve also noticed a few times that the “call AC0” where the Initialization Function is called on line 228 gets lost, or at least does not return.

 I’m probably doing something wrong, but is there a way to get breakpoints to work consistently in this assembly code, as the breakpoints don’t always appear to be working in stopping the processor, at least not consistently?  The breakpoints I’m setting show up in the source code as blue dots on the far left, and they are listed in the “View Breakpoints” menu.  This would really make debugging this easier.

 But most importantly, please let me know what I should try next or what information I can provide to you that might help understand what’s going on?  Would the map file help?

 One question I have is if there are any restrictions on what the _auto_init function can handle?  Such as the size of the cinit or pinit tables?  The following listings for the cinit and pinit are “cut and pasted” below, from my map file if that might help.

 Thanks again,

Tom

.cinit       0   [ 00040000 ]  00020000          *   00000306  

                 [ 00040000 ]  00020000          *   000000e4   freq_domain_proc_boom.obj (.cinit)

                 [ 000401c8 ]  000200e4          *   000000ad   i2s.obj (.cinit)

                 [ 00040322 ]  00020191          *   0000004c   dma_routines.obj (.cinit)

                 [ 000403ba ]  000201dd          *   0000003a   compress2.obj (.cinit)

                 [ 0004042e ]  00020217          *   0000002d   rts55x.lib : lowlev.obj (.cinit)

                 [ 00040488 ]  00020244          *   0000002a              : defs.obj (.cinit)

                 [ 000404dc ]  0002026e          *   0000001d   key.obj (.cinit)

                 [ 00040516 ]  0002028b          *   0000001c   tones.obj (.cinit)

                 [ 0004054e ]  000202a7          *   00000015   csl_mmcsd_ataIf.obj (.cinit)

                 [ 00040578 ]  000202bc          *   00000014   SD_boot.obj (.cinit)

                 [ 000405a0 ]  000202d0          *   0000000a   rts55x.lib : _lock.obj (.cinit)

                 [ 000405b4 ]  000202da          *   0000000a              : exit.obj (.cinit)

                 [ 000405c8 ]  000202e4          *   00000005   usbstk5505_i2c.obj (.cinit)

                 [ 000405d2 ]  000202e9          *   00000004   aic3204_config.obj (.cinit)

                 [ 000405da ]  000202ed          *   00000004   aic3204_spi.obj (.cinit)

                 [ 000405e2 ]  000202f1          *   00000004   main.obj (.cinit)

                 [ 000405ea ]  000202f5          *   00000004   rts55x.lib : errno.obj (.cinit)

                 [ 000405f2 ]  000202f9          *   00000004              : fopen.obj (.cinit)

                 [ 000405fa ]  000202fd          *   00000004              : memory.obj (.cinit)

                 [ 00040602 ]  00020301          *   00000004   timer.obj (.cinit)

                 [ 0004060a ]  00020305          *   00000001   --HOLE-- [fill = 0]

SECTION ALLOCATION MAP

(Addresses surrounded by []'s are displayed for convenience only!)

output                                                          attributes/

section   page  orgn(bytes) orgn(words) len(bytes) len(words)   input sections

--------  ----  ----------- ----------- ---------- ----------   --------------

.pinit       0   [ 00040000 ]  00020000          *   00000000   UNINITIALIZED

.stack       0   [ 000000c0 ]  00000060          *   00001800   UNINITIALIZED

I just did another quick test, where I removed some of my code to make the program size smaller, and the assembly code breakpoints work and also the code doesn't get lost.  But, I do need all of the code to work.

Tom

With some more testing, I've found:

1 ) The auto_init works when I run a subset of my code.  I can set breakpoints in the code and it doesn't get lost on initialization.

2 ) With my "full" set of code, the auto_init function gets lost, and breakpoints don't work with the auto_init function.  But I can "single step" through the auto_init function.

So the question is why the auto_init function "flakes out" ( gets lost and breakpoints don't work ) when my larger program is run.

In the debugger, I can see that with the larger code base the auto_init function is in the 0x481D6 to 0x4821F memory range.  Which is not in the 0x4E000 to 0x4FFF range used by the bootloader as described on page 2 of SPRABL7A.

With the smaller code base, the auto_init function starts in the 0x35CCA area of memory.

Is there any reason, that breakpoints and code does not operate correctly or might be getting corrupted in the 0x481D6 area of memory?

Tom