Mity CPU Platforms » MityDSP-L138 (ARM9 Based Platforms)

Edwin,

Unfortunately we have not used the XDS200 on any platform so we don't even have one to try and reproduce this issue. I'm sure this is just outdated information but section 7.1 of this wiki http://processors.wiki.ti.com/index.php/OMAP-L138_Software_Design_Guide#TI_XDS_Hardware_Emulators only recommends the XDS100, XDS510 and XDS560 emulators.

That being said this E2E post mentions that a Full License must be used on CCS to support the Emulator (https://e2e.ti.com/support/development_tools/code_composer_studio/f/81/t/287193).

Our recommended emulator is the XDS510 (https://support.criticallink.com/redmine/projects/arm9-platforms/wiki/DSP_Development_Tools) where possible.

Thanks,

Alex

From TI's web site the XDS510 & XDS560 are both obsolete?
I will try searching the TI web site.

Thanks for the update. I will see if we can get one in house. In the mean time try searching TI's e2e to see if anyone has reported having similar issues. Let us know if you find a solution.

Edwin wrote:

I will try searching the TI web site.

Good idea. Let us know if you find something that helps.

I have gotten a little further. The "Test Connection" now seems to work. So I guess Ubuntu can talk to the XDS module.

When I select my project for debugging I receive the following message:
C674X_0: Error connecting to the target: (Error -1180 @ 0x0) Device is held in reset. Take the device out of reset, and retry the operation. (Emulation package 5.1.232.0)

From the TI site it looks like the ARM is/could be holding the DSP in Reset mode. I can run the "Hello World DSP" sample. I started this program and then selected my program to debug and it looks like I have gotten further. It looked like something was downloaded, but not I have a window with "Configuring Debugger (may take a few minutes on first launch)". Then "Initializing ICEPICK_C (cannot be canceled)". This has been running for some time now. Many minutes.... The green light on the side with the "red" wire, ( "top" light) is flashing.In what appears to be bursts of three.

I am on Ubuntu 14.04 with CCS 5.5.

Edwin McKay wrote:

I have gotten a little further. The "Test Connection" now seems to work. So I guess Ubuntu can talk to the XDS module.

Did you do anything to get this test to pass?

When I select my project for debugging I receive the following message:
C674X_0: Error connecting to the target: (Error -1180 @ 0x0) Device is held in reset. Take the device out of reset, and retry the operation. (Emulation package 5.1.232.0)

From the TI site it looks like the ARM is/could be holding the DSP in Reset mode. I can run the "Hello World DSP" sample. I started this program and then selected my program to debug and it looks like I have gotten further.

Makes sense. I'm pretty sure the DSP's clock isn't enabled until it is programmed.

It looked like something was downloaded, but not I have a window with "Configuring Debugger (may take a few minutes on first launch)". Then "Initializing ICEPICK_C (cannot be canceled)". This has been running for some time now. Many minutes.... The green light on the side with the "red" wire, ( "top" light) is flashing.In what appears to be bursts of three.

I am on Ubuntu 14.04 with CCS 5.5.

Talking with some of the DSP guys here. They see this on occasion and usually have to retry the connection. It may be necessary to unplug the USB cable from the debugger to get CCS to quit this "Initializing".

To debug the DSP code with DSPLink the code must be loaded using the ARM and the debugger is set to load symbols only. If you need to debug initialization code then you can set a delay loop at the beginning of your code so you can break in with debugger.

To get at least pass the "Test Connection" I installed the drivers. I must have missed that step when I installed CCS 5.

What are steps to debug a DSP application?
For instance how would I debug the "Hello World DSP" program? Do I run the Linux program that loads the DSP out file? Then start the debugger?
For "the debugger is set to load symbols only" I found a "Load Symbols only" option under the "Program" tab for "Debug Configurations", is that the correct one?
Someone here had some notes that said to uncheck the "Auto Run Options" under the "Target" tab. I am not sure if that was necessary or just for their application.

I see the "initializing ICE Pick" window briefly this morning, so I'm getting pass that portion.

I placed "bool bWaitForMe = true;
while (bWaitForMe) ; // wait for the debugger here...." in the "int main" routine and placed a break point on the "while".

It looks like I can debug the Hello World program, so now I will try the real application.

Edwin McKay wrote:

To get at least pass the "Test Connection" I installed the drivers. I must have missed that step when I installed CCS 5.

Gotcha, yeah thats an easy screen to miss.

What are steps to debug a DSP application?
For instance how would I debug the "Hello World DSP" program? Do I run the Linux program that loads the DSP out file? Then start the debugger?

Yes

For "the debugger is set to load symbols only" I found a "Load Symbols only" option under the "Program" tab for "Debug Configurations", is that the correct one?

Yes

Someone here had some notes that said to uncheck the "Auto Run Options" under the "Target" tab. I am not sure if that was necessary or just for their application.

I don't know.

I see the "initializing ICE Pick" window briefly this morning, so I'm getting pass that portion.

I placed "bool bWaitForMe = true;
while (bWaitForMe) ; // wait for the debugger here...." in the "int main" routine and placed a break point on the "while".

This seems reasonable to me.

It looks like I can debug the Hello World program, so now I will try the real application.

Well sort of debug. It hit the break point, I changed the waitForMe variable and stepped one line. But after stepping again, the screen goes "grey" and appears to lock. These messages appear:
C674X_0: Can't Single Step Target Program
C674X_0: Trouble Reading Memory Block at 0xc610ac0e on Page 0 of Length 0xd7: (Error -2172 0xC610AC0C) Unable to communicate with the emulator. Confirm emulator configuration and connections, reset the emulator, and retry the operation. (Emulation package 5.1.232.0)
C674X_0: Trouble Reading Memory Block at 0xc610ac22 on Page 0 of Length 0xcf: (Error -2172 0xC610AC20) Unable to communicate with the emulator. Confirm emulator configuration and connections, reset the emulator, and retry the operation. (Emulation package 5.1.232.0)
ICEPICK_C: Error: (Error -2172 0x0) Unable to communicate with the emulator. Confirm emulator configuration and connections, reset the emulator, and retry the operation. (Emulation package 5.1.232.0)
ICEPICK_C: Unable to determine target status after 20 attempts
ICEPICK_C: Failed to remove the debug state from the target before disconnecting. There may still be breakpoint op-codes embedded in program memory. It is recommended that you reset the emulator before you connect and reload your program before you continue debugging
C674X_0: Trouble Reading Memory Block at 0xc610ab90 on Page 0 of Length 0xcd: (Error -2172 0xC610AB90) Unable to communicate with the emulator. Confirm emulator configuration and connections, reset the emulator, and retry the operation. (Emulation package 5.1.232.0)
C674X_0: Trouble Reading Memory Block at 0xc610ab9c on Page 0 of Length 0xc5: (Error -2172 0xC610AB9C) Unable to communicate with the emulator. Confirm emulator configuration and connections, reset the emulator, and retry the operation. (Emulation package 5.1.232.0)
C674X_0: JTAG Communication Error: (Error -2172 0x0) Unable to communicate with the emulator. Confirm emulator configuration and connections, reset the emulator, and retry the operation. (Emulation package 5.1.232.0)
C674X_0: Failed to remove the debug state from the target before disconnecting. There may still be breakpoint op-codes embedded in program memory. It is recommended that you reset the emulator before you connect and reload your program before you continue debugging

I have to reset the Emulator to get CodeComposer to work again.

Would "you" consider this normal? I have encountered other touchy systems and have just learned to live with it and expect lots of resets. If this is not normal then maybe I am doing something wrong with the debugger.

I have tried to debug our main application. I copied the "waiting" loop from the Hello World app to the main. Whenever I try to connect to the target I receive this error:

Can't find a source file at "/db/vtree/library/trees/cuda/cuda-u44x/src/ti/bios/src/misc/utl_halt.c"
Locate the file or edit the source lookup path to include its location.

The main application links in the dsplink files along with 10M of other data/libraries.!

I assume my programming is crashing somewhere causing the "halt" routine to be called.
For now, my main is simply:

int main(int argc, char* argv[]){
int bWaitForMe = 1;
int iCounter = 0;
int iCounter2 = 0;
while (bWaitForMe) {
iCounter++; // wait for the debugger here....
if (iCounter > 10000) {
iCounter2++;
iCounter = 0;
}
}
}

The "real" program has some global objects created in the main.cpp file, so I assume those are created before the main() routine is run? Maybe it is crashing there.

Hello Edwin,

I agree that since the debugger is looking for utl_halt.c something has gone wrong before main.
Obviously, try disabling those other things and then if it works, start putting them back.

When you did succesfully debug the Hello World app, I trust you were able to step over the code then.

As for the auto run, you probably do want it to run to initialize and catch the application in the while loop.

Dave

Yes, I could step through the HelloWorld app. Is there anything else that might run before the main()?
I have changed all the objects from 'static' declarations to dynamic 'new's. Still no luck.
Well, all the ones in main.cpp. There are hundreds of others in the other files. So without a call stack showing where the crash has ended up it is probably a lost cause.

These are the steps I take to debug the DSP program. Can anyone confirm that these are correct, necessary etc..
Build DSP code on Ubuntu in Debug mode.
scp the .out file from Ubuntu to the MityDSP /home/root folder.
On the MityDSP, run a program that "loads" the DSP.out file. (The program does very little else, it was from the HelloWorld example.)
(On the MityDSP I see a "PROC Load successful" message, so I assume the .out file was loaded correctly & completely.)
Back on Ubuntu in CodeComposer, I select the 'debug' beetle icon for my selected project. The debugger is set to only 'load symbols' not the program.
Am I correct in assuming the Code Composer debugger can *never down load code to the DSP side of the MityDSP, we always have to copy the file ourselves?
I have placed a "while(waitforme) ;" at the start of the main() function to capture the program before it can do anything.

Hello Edwin,

Those steps do appear correct.

All project I have done on the L138 have used dsplink to communicate between the ARM and DSP. To do this,
the ARM code must load the DSP code.

There may a couple ways to get past your hurdle.
1:You may be able to exclude the other files from the project, eliminating the effect they have.
2:You may be able to temporarily remove the dsplink from the DSP code, and go ahead and load the entire app (not just symbols) using the debugger. I'm
pretty sure you would still need to have the ARM load the DSP to make sure it has everything it needs to run. It may be safer to use the Hello World
with the while loop. I haven't tried this, but expect it would work.

Dave,
Thanks for the reply.
1. Easier said than done ;)... The project is very "integrated". I have pared it down to something basic.
2. For now I have only DSP code and no comms back to the ARM.

For what I have now, if I right click the project and select "Debug As .. 1 Code Composer Debug Session" it seems to stop at the top of the main() and I can step from there. I tried this with the other much larger project, but nothing seems to happen.

Just to confirm, to debug any DSP code, you have to "load" it first. That is the debugger can "load" new DSP code, so for every change I have to compile, copy to MityDSP, then run the loader program? It also appears I have to reboot every time as well. I have tried Control-C to stop the ARM program or can the ARM program simply load the DSP and then exit? Then I can just re-load the DSP code again?

As I mentioned, you may be able to use the debugger to load the application. I believe you should load
some DSP code using the ARM first to initialize the DSP processor. Then after you connect the debugger you
can load your application and hopefully find the problem with initialization. I would not expect dsplink
communication to work between the DSP and the ARM doing this, and if not removed it may cause a problem (may).

As for Control-C not allowing for reloads, it would not surprise me that some part of the processor is left in a state
that causing a problem.