CCS Target clock and AET resources

JHi said:

I'm having problem with the clock feature in CCS. I'm working with the 28035 Piccolo, BlackHawk USB2000 and CCS v.4.1.3.00038. Every time I try to enable the clock from Target menu I get the error: C28xx: Error programming AET Job: This task cannot be accomplished with the existing AET resources. I'm running my program from Flash and try to clock interrupts which are in RAM.

Any advice how I can get it to work? Restarting everything doesn't help.

JHi,

The error message is the same as mentioned in this thread.  Can you update your drivers and see if the issue goes away? 

http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/t/60276.aspx

-Lori

PS Moving to the Code Composer Studio forum

Yes, I also updated my drivers when I updated the CCS.

I can reproduce this and it is currently under investigation

Hi all,

It is probably that JHi is running code out of flash and CCS sets the default breakpoints (end of program and CIO), which are probably in FLASH and are therefore HW breakpoints, thus making full use of AET unit. Try changing the CCS settings to not place these breakpoints (I don't know where you do this in CCS4) so that AET unit will not be in use and you could probably use the clock feature of AET unit.

To TI folks: a user guide for the AET unit would be very welcome (maybe with some sample code and examples how to use various features) preferably with full register descriptions as the only description of AET is in spra820 - "Online Stack Overflow Detection on the TMS320C28x DSP"

Regards, Mitja

Mitja,

I can reproduce this by just connecting to the 28035 and try to enable the profile clock. i don't have any program loaded so no exit point or CIO breakpoints should be in use.

It seems specific to the BH USB emulator. I used a BH USB510L to reproduce it. But no issues with the XDS560 PCI one.

Also the issues does not occur with 4.1.2. So the updated BH drivers in 4.1.3 could have introduced some issue. We are still investigating

ki

Ki-Soo Lee said:

It seems specific to the BH USB emulator. I used a BH USB510L to reproduce it.

Should clarify that it is specific to BH USB2000 and 510L. The XDS560 based ones like BH 560m and 560LAN are fine

This issue is related to the issue reported on this thread:

http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/p/60276/222366.aspx#222366

The new Blackhawk update addresses this issue (available from the Update Manager). I just verified this on my environment.

Thanks

ki

I have installed this latest patch and it doesn't help. I said this on my first post. The only thing in my update manager for Blackhawk is: Blackhawk CCSv4 Emulation 4.0.1.2. This should be older than what I have.

Edit: I tried again now, and it seems to work, I didn't do anything special. Well doesn't matter. Thanks for the replies.

Edit2: There seems to be lot of problems with the AET still. Now I don't have any breakpoints and ahd the clock enabled and when I reset mcu and wanted to run to mains() it could't do that. Then I disabled the clock and I was able to run to mains().  It seems that it won't release the AET resources even if I remove the breakpoints from the manager.

Edit 3: Can't do clocking. It worked for a while and now again AET resources problem. I don't have any break points or anything. I also restarted the emulator.

The clock still doesn't work. I have no break points or anything and it still complaining about AET resources. Am I the only one having this problem? Are you going to do anything about this?

I got the clock working when using this:

Posted by JohnS

Try releasing the AET resources manually  (refer to spra820 - "Online Stack Overflow Detection on the TMS320C28x DSP") if it works, maybe you can make it automatic via GEL file

Regards, Mitja

I don't know if I understood correctly but I removed the tap from Debugger options for Enable CIO and Halt at program termination. The clock works now but I have to check if this is permanent. By the way, I removed the tap from Halt at program termination and pressed Remember my settings. Still if I restart the CCS there is a tap in this point. Is there a problem saving configurations or can't you save this special setting?

Hi,

I meant to releasing (first check if they are in use altogether) AET resources via watchwindow (namely check EVT0_ID and EVT1_ID registers to see wheather AET units are in use and by whom, and release AET units via EVT0_CNTL and EVT1_CNTL registers)

I hope I am on the right track as I don't have BH pods neither CCS4.x.y

Regards, Mitja

JHi said:

I have installed this latest patch and it doesn't help. I said this on my first post. The only thing in my update manager for Blackhawk is: Blackhawk CCSv4 Emulation 4.0.1.2. This should be older than what I have.

Do you not see Blackhawk 4.1.3.3 update?

As I said in my first post I updated my BH drivers also. (ID: com.blackhawkdsp.ccstudio.emulation.4133, Version: 4.1.3.3)

Mitja Nemec said:

Hi,

I meant to releasing (first check if they are in use altogether) AET resources via watchwindow (namely check EVT0_ID and EVT1_ID registers to see wheather AET units are in use and by whom, and release AET units via EVT0_CNTL and EVT1_CNTL registers)

I hope I am on the right track as I don't have BH pods neither CCS4.x.y

Regards, Mitja

I wonder where I can find these registers in CCS4. Those are not in the Register view and if I use the memory window to see location 0x084F EVT0_ID WP0 event ID register there is nothing.

I get the clock working by removing (every time I has to do this because CCS can't remember settings even though I press remember my settings button) the: Halt at program termination.

These are memory mapped registers practically undocumented by TI. If you put them in watch window, place HW brake-point and refresh watch window you should observe a change. Note that for one of the you must make a single step by CPU to update properly (maybe it is shadowed?). When you disable the brake-point, watch-point unit should be released (after a single step by CPU). If not maybe you could release it manually.

The 'Halt at program termination' probably places a HW brakepoint thus claiming one watch-point, why CCS can't remember is beyond me.

Regards, Mitja

Mitja Nemec said:

These are memory mapped registers practically undocumented by TI. If you put them in watch window, place HW brake-point and refresh watch window you should observe a change. Note that for one of the you must make a single step by CPU to update properly (maybe it is shadowed?). When you disable the brake-point, watch-point unit should be released (after a single step by CPU). If not maybe you could release it manually.

The 'Halt at program termination' probably places a HW brakepoint thus claiming one watch-point, why CCS can't remember is beyond me.

Regards, Mitja

EVT0_ID: Identifier not found

EVT1_ID: Identifier not found

EVT0_CNTL: Identifier not found

Suggestions?

As these registers are undocumented by TI, they are not defined within device peripheral header files

EVT_CTL0 == (int)*0x084E

EVT_CTL1 == (int)*0x082E

EVT_ID0 == (int)*0x084F

EVT_ID1 == (int)*0x082F

I managed to put one breakpoint and the value in EVT_CTL0 == (int)*0x084E changed from 0 to 1058. And when I tried to put another one the break point came as gray (not activated). EVT_CTL1 == (int)*0x082E = 0 (always, not depending on breakpoints) , (int)*0x084F = -28670 (always, not depending on breakpoints) , (int)*0x082F = 0 (always, not depending on breakpoints) .

So here is what happens when I set up a breakpoint.

At the beginning all registers read zero, when I put one break-point I have the same change that you do (EVT_CTL0 = 1058, EVT_ID0 = -28670). If I clear the break-point EVT_CTL0 returns back to zero, while EVT_ID stays the same. If I put two break-points, the situation is the same but for EVT_CTL1 and EVT_ID1 registers changing to the same values (and CTL register cleraring when removing break-point)

If you get the same behavior than you have no option but waiting for updates, but if there is a difference, you could wrigte GEL script that would put these register in proper state and maybe that would help

Regards, Mitja

The difference is that I can't set the second breakpoint. EVT_CTL1 and EVT_ID1 are both zero. How and which Gel script I have to change to get this other one work also? Or is this driver problem?

It's probably a driver problem. Be sure to check if you can write values in second watchpoint unit. If not maybe you have problems with CCS memory map, which might block you and CCS/emulator to write into it, therefore preventing you to place second breakpoint.

My idea was that if CCS/emulator did not release breakpoints automatically, thus preventing CCS/emulator to use another feature of AET unit, you culd write a gel script that would execute let say at reset and would write proper values intoe AET unit to release breakpoints.

You still could set second breakpoint by writing proper values in watchpoint registers, but I have never done this manually so I should again refer you to SPRA820 as it is the only description of AET/watchpoints.

Regards, Mitja