debug for notify example using ccs on DM8148

Miao,

The old SysLink 'samples' have been deprecated. I suggest you use the new 'examples'. Unfortunately, we did not start shipping the new examples until SysLink 2.10. I suggest you download the last release, SysLink 2.21.03.11, and use the examples from there. They should work fine with your working release. Look in the following folder.

SysLink_2_21_03_11/examples/archive/TI814X_linux_elf_ezsdk

You don't need to convert these examples into CCS projects in order debug them. You can build them outside of CCS, load the executables to your target file system, and run them. Once the DSP is up and running, you can use CCS to load the symbols and then simply connect to the DSP. At that point, you can start debugging.

This is also true of the old SysLink samples, you don't need to make them into CCS projects.

Make sure that your CCS Debug Configuration does not have any gel files associated with the DSP. You want CCS to connect without issuing any gel commands.

I always load symbols before I connect, but it really does not matter. Either way works fine.

You can use the Source Lookup Path option to make it easier for the debugger to find your source files.

CCS > Window > Preferences
C/C++ > Debug > Source Lookup Path
Add > Path Mapping > OK
Name: <add your favorite name>
Add
Compilation path: <the actual path the compiler used to build your source file>
Local path: <the same path mapped to your PC>

The two warnings you mention above are safe to ignore.

The executable file size is dependent on the compilation options you use. But what's more important, is the actual program size which is loaded to the target. Look in the generated map file. These are also controlled by compilation options.

When you connect to the DSP, it could be at any random point. If the DSP is idle, then it will be somewhere in the idle loop. Sometimes, you might catch it during the timer interrupt. Either way, set a break point at some application level, then run until you hit that break point.

~Ramsey

Miao,

In CCS, you also want to make sure there is no initialization script for the DSP. Double-click on your ccxml file. This will open your configuration script in the graphical editor. At the bottom of the window, you should see three tabs: Basic, Advanced, Source. Click the Advanced tab. Select the DSP in the connection browser. On the right side, you should see a properties page. Look for one called 'Initialization Script'. Make sure it is empty. Be sure the click the save button if you make any changes.

In your step #3 above, are you using slaveloader to load and run the DSP? Something like the following command:

slaveloader startup DSP server_dsp.xe674

This will load and run the DSP. If you are using the SysLink example ex02_messageq, then the DSP will be spinning on Ipc_start. You own program might be doing something else.

At this point, you can launch your CCS debug session, load the DSP symbols, and then connect to the DSP. Set a break point on Ipc_start() and then run. It should immediately hit the break point. This will keep happening because it calls Ipc_start() in a loop.

For the ex02_example, when you run the HOST side program, the DSP will eventually go to Server_exec(). Set a break point there and delete the first one. Then run the DSP. It should keep running.

Now you are ready to run the HOST program. Enter the following command:

app_host DSP

At this point the HOST program will attach to the DSP and send a message. You should see a few print statements. Then it waits for a reply message. At this point, you should see the DSP hit the break point in Server_exec().

On the DSP, you should be able to step through the code. When the DSP sends a message back to the HOST, you should see another print statement.

In your step #6 above, I think the problem is that you set a break point on the DSP at main(). But the DSP had already run past this point, so it will never hit this break point. Remember, that when you load and run the DSP, it will run normally, it does not stop in main().

If you use CCS to load and run the DSP directly, then the SysLink driver on the HOST does not know the DSP has been loaded. The SysLink driver will not have the correct runtime state. When you try running the HOST program, it will fail with an error. You must use SysLink to load and run the DSP.

~Ramsey

Miao,

When using SysLink and slaveloader to load the DSP from the HOST side, you should not reload the DSP again using CCS. You should just load symbols in CCS and then connect to the DSP.

When using CCS to reload the DSP, it causes the initial runtime context to be lost. This will cause problems with the SysLink driver running on the HOST. In your test above, you are probably getting lucky. Since the DSP did not proceed very far, there was very little context to loose. However, if the DSP had run beyond the IPC attach phase, and then you reloaded the DSP, it would certainly not make it though IPC attach a second time because the SysLink driver on the HOST would not be doing the IPC attach a second time.

Again, I think your are just gettign lucky with the CCS reload of the DSP. The recommended procedure is to load symbols and connect. There is no CCS documentation on this topic.

~Ramsey