"Request for non-existent AET job"

Could you try renaming C:\CCStudio_v3.3\cc\bin\ctools.dll? Just change the name to something else (like ctools.bak) and see if the error goes away.

Thanks

ki

That did not help.  Stepping out of a function while debugging still does not work and, while I don't see the "AET job" messages, I do see an empty dialog box pop up every time I load a program.

So far I've traced the problem to a specific code change.  The debugger works without this code, and fails with the code.  Unfortunately, I didn't write the library so I'm still trying to understand what it's doing.  It appears that it links in codecs for JPEG and BITMAP libraries.  These codecs should be from TI, so why would they cause a problem with the debugger?

I'm still looking for an answer to this problem.  I contacted support, but they directed me back here.

Can anyone tell me what the "Request for non-existent AET job" means?  What is this error telling me?

I did find more information out about the library that is causing this error.  It is a wrapper build around the TI XDAIS framework.  Another engineer took the XDAIS codecs and build this library so we could link against it without requiring everyone install the XDAIS packages.  He installed XDC, CGtools, and framework components 2.23.01.  He then build a wrapper around it and turned it into a library.  Somehow including this library is affecting my debugger.  How?  What can I do to figure out how to fix this?

I found some previously reported issues with the same warning being generated when resetting CPU, but they were addressed in CCS 3.3 SR12 which looks like the version you are already using.

I would imagine this message would be related to some target action being taken that the emulation software thinks requires a AET (advanced event triggering) job. So I'm not sure how it could be related to the library you are linking in.

Do you have any hardware breakpoints/watchpoints set in your debug session? Does doing a CPU reset or stepping over code when all other breakpoints are disabled change the behavior at all? What are the exact debug steps you perform in CCS when this message appears? Also, if you are using a GEL file you may want to check if there are there are functions related to setting or clearing HW breakpoints in there as well.

Aarti said:

Do you have any hardware breakpoints/watchpoints set in your debug session?

No.  Just a software breakpoint.

Aarti said:

What are the exact debug steps you perform in CCS when this message appears?

1. Set a software breakpoint somewhere in the code. 
2. Load a program and run.  Wait until the code hits the breakpoint.
3. At the breakpoint, click the "Step Out" button (Shift + F11).  Notice that the debugger does not step out of the function.  Control (the yellow arrow) remains in the same location, but the processor appears to be running (the Run button is grayed out).  If you stop the processor right now, control is still at the breakpoint.
4. Reset the processor.  You may or may not see the "AET job" message.
5. Reload the program.  You will see the "AET job" message now.

Aarti said:

Does doing a CPU reset or stepping over code when all other breakpoints are disabled change the behavior at all?

I'm not entirely sure what you are asking.  I do know that you can perform other debug operations (Step Into and Step Over) following breakpoints and still successfully reset the processor and reload the program afterward.  The problem seems to start once you've attempted to Step Out while debugging.

Aarti said:

Also, if you are using a GEL file you may want to check if there are there are functions related to setting or clearing HW breakpoints in there as well.

I'm using the GEL file available here:  http://support.spectrumdigital.com/boards/evmdm365/revc/files/evmdm365.gel

I've modified settings for PERI_CLKCTL, PINMUX1, and added a "GEL_MapAddStr" call for EDMA Parameter RAM.  I don't see any calls for setting or clearing HW breakpoints, but I admit I'm not exactly sure what I am looking for.

Finally, this problem happens on two different machines.  So it does not appear to be specific to my setup or my build of the program.

I checked with the development team and they said that this message was caused by an internal error in AET(advanced event triggering) software within CCS, and was fixed for CCSv4. I'm not sure where you are in your project schedule and if it is feasible for you to update to CCSv4 at this time, but if you are able, you can download and try it out. If you are unable to update at this time, and since it seems that the message does not really disrupt your debug environment, you could ignore the message when it occurs.

CCSv4 is available for download at http://processors.wiki.ti.com/index.php/Download_CCS and you can try it out with an evaluation license to begin with. The CCSv4 Getting Started Guide is a good reference to help you get started with this version.

Yeah, I don't think going to CCSv4 is an option although I will ask.

While the message doesn't disrupt the debug environment (aside from being annoying), I do lose the ability to "step out" of a function while debugging.  That is very frustrating, especially when I'm debugging code outside of the library that is causing the problem.  Is there a work around?  I still don't understand how new code is causing the debugger to break.  What is the bug that is causing this error?

The problem with "step out" is likely unrelated to the AET message. AET is the advanced emulation capability related to hardware breakpoints/watchpoints/counters etc. The particular AET message you are getting is coming due to a bug in the internal AET software, but I'm not sure what triggers it.

However, since the real problem you are having is with stepping out after halting at a software breakpoint, I don't believe that is related to the AET bug. It is possible there was a bug in CCS 3.3 causing this "step out" issue. It would be interesting to see if the issue also occurs with CCSv4 as there have been many bug fixes and improvements since CCS3. And if the issue still exists in CCS4 and we could get a test case that demonstrates it, we could definitely look into fixing it.

After some discussion, we are too late in the project to switch to CCSv4, especially if the switch requires changes to the project files.

I can live with the AET messages because, while annoying, they don't appear to break anything.  However, I would really like a fix for the "step out" debugging problem.  Can I get a fix for the problem if I'm still using CCSv3.3?

Unfortunately we are no longer making fixes for CCS 3.3.

That is disappointing. 

Aarti said:

It is possible there was a bug in CCS 3.3 causing this "step out" issue.

I understand I probably won't be able to get a fix, but is there anything more you could tell me about potential issues with the "step out" function?  Perhaps there is something I could do with the code/library that would avoid this issue.  The library is including TI codecs, so please keep that in mind.  Thanks.

Is the function where you are halted at a breakpoint making calls into this library? Do you know if the library was built with debug information (-g compiler option), (ie) if you step into code within the library do you see the source/asm correlation?

When you trying the step out are you within your application code or within the library code?

Are you able to try the following:
- manually set a breakpoint at the location where it should have halted if the "step out" had worked
- step into the halted function as you did previously
- Run, and see if you hit the breakpoint where the step out should've halted

Since stepping also requires breakpoints, I'm just wondering if the driver is having trouble setting a breakpoint at that location for some reason.

Aarti said:

Is the function where you are halted at a breakpoint making calls into this library?

No.

Aarti said:

Do you know if the library was built with debug information (-g compiler option), (ie) if you step into code within the library do you see the source/asm correlation?

It was not.  We are linking against a release version.  I did find a debug version and tried linking against it.  I still see the problem.

Aarti said:

When you trying the step out are you within your application code or within the library code?

I'm in the application code.

Aarti said:

Are you able to try the following:
- manually set a breakpoint at the location where it should have halted if the "step out" had worked
- step into the halted function as you did previously
- Run, and see if you hit the breakpoint where the step out should've halted

Yes, I am able to do that.

Any updates?

I know you mentioned it was too late in your projec to switch to CCSv4, especially if it required changes to the project files. You can still stay with the same version of code generation tools but just use the CCSv4 debugging environment to debug the project. In other words, you can set up the build settings in CCSv4 to use the version of codegen tools you want, therefore you will still be generating a functionally identical executable as before.

To start off, you could even try to just take the executable built with CCS 3.3 and load and debug it using CCS v4 to see if the issues with "step out" exist in CCSv4. You could download and try out the evaluation version of CCSv4. If the "step out" issue still exists with CCSv4 and you are able to provide us with a test case that reproduces it, we can investigate it further and hopefully fix it for v4.