Stack problem on CCS4 - private object data is over-written with tempoarary device address data.

Hi Julian,

In order to investigate this further we would need some additional information.

Which specific version of CCS are you using and which version of C2000 code generation tools? (the project properties->CCS Build should tell you the version of cgtools)
Which target platform/board are you running on?

It sounds like the problem may be due to the compiler generating incorrect code, but in order to confirm that we would need a test case that reproduces the problem. Before going that route though it might be worth trying to use the latest version of codegen tools in case its a bug that was already found and fixed. The latest codegen tools for C2000 is 6.0.2. You can update to this version from CCS by going to Help->Sotware Updates->Find and Install. After installing this verison you can update your project to use this latest version: http://processors.wiki.ti.com/index.php/Compiler_Installation_and_Selection

If the issue still persists with this version of the compiler tools, please provide us with a example project that demonstrates the problem so we can duplicate it and look into it further.

Thanks for getting back.  I'm running 4.2.4.00033 of CCS, and TiV5.2.11 of the cg tools.

I tried an update, but wasn't sure what to select when doing an update - see screenshot 2 attached. When I carried on from this view, I was warned there would be a conflict, and things may not work - screenshot 3.  Help!!    p.s. - I'm working on some example code to send you.      Julian.

4426.Stack problem screenshot 02.rtf

3554.Stack problem screenshot 03.rtf

Julian Woloszczuk said:

I tried an update, but wasn't sure what to select when doing an update - see screenshot 2 attached. When I carried on from this view, I was warned there would be a conflict, and things may not work - screenshot 3.  Help!!    p.s. - I'm working on some example code to send you.      Julian.

Go to Help->Software Updates->Find and Install. Then select "Search for new features to install" instead of "Search for  updates of currently installed features". Reason for this is explained here: http://processors.wiki.ti.com/index.php/Updating_CCS. This should show you Code Generation Tools from where you can expand C2000 and find the latest version.

Regarding the warnings about the conflict, that is a known issue where this message appears when there are multiple versions of BIOS/RTSC tools installed. It is ok to ignore the message.

OK, I'll try it again. By the way, I'm using a TMS320F2812 on my client's own platform.      Julian.   p.s. - I'll be off home soon, so I'll give you an update in the morning.  Have a nice day :-)

Hello,  I've now tried the project with cg tools version 6.0.2 - still the same problem. I've also tried with different levels of optimisation - still the same.    So, I've pulled together some files that can be built by yourselves, so you can see if it demonstrates the same issue. Files attached. 

Main.cpp has a timer that matures every half a second, and writes to the console. This is the bit that works.

tryatimer.cpp has a timer that matures every second, and should also write to the console. However, the callback pointer gets corrupted on the stack, so hits an illegal instruction.

   Thanks for your help,

       Julian. 

8508.project for ti.zip

The way to see it going wrong is to put a breakpoint, or run till line 468 of timers.cpp. When the callback is for the timer in main.cpp, the correct address is loaded into XAR7, just before the 'LCR' instruction.  When the callback is for the timer in tryatimer.cpp, the incorrect address is loaded into XAR7, just before the 'LCR' instruction.  

These experiments have all been carried out on our 2812 target board. My colleague on another site has the same files I've sent you, and he will be attempting to build and run for the 28335 device he has on an evaluation board, just to see if it makes any difference.

Let me know if you need any more information. 

Julian,

Sorry about the delayed reply. I have been trying to duplicate this on a F2812 eZdsp but am having trouble running the code till line 468 of timers.cpp. The code gets to line 466: if (next_trigger_date <= gTicks), but does not get to the code inside the if condition. I'm not sure if it has to do with the specific target board being used, but please let me know if you have any thoughts on this.

In the meantime, I also started looking at the assembly code generated by the compiler in the hope that there might be enough information there to point out the problem. I compiled the project with -k -ss option to generate the assembly file with C source interlisted and am attaching a zip of the .asm files. Could you point out in timers.asm (or one of the other .asm file) exactly which line of assembly is loading the incorrect value? If we have this information I could see if that is sufficient for the compiler team to further analyze the issue without having to run the code on a target board.

3247.asmfiles.zip

Hello Aarti,

   Thanks for getting back.  You will get inside the condition once 'gTicks' increments enough times - this is managed by CPU timer T2 - maybe your timer isn't running?

Anyway, you can hopefully see the beginning of the problem before the timer matures, as follows.

In main.cpp, after the slow timer callback is created, memory location 0x8008 will contain 0x3DB46E - the VFT for ITimerCallback in main.cpp, whose last element contains 0x3DA933 - the address of the callback routine in main.cpp.

In main.cpp, after the 'tryatimer' object is created, memory location 0x8014 will contain 0x3DB47A - the VFT for ITimerCallback in tryatimer.cpp, whose last element contains 0x3DA741 - the address of the callback routine in tryatimer.cpp.

In main.cpp, when timersDriver.Superloop is called, things go wrong. in timers.cpp, in superloop, a call is made to the 'Touch' routine. In assembler, address 0x3d92B7 - the 'LCR Touch' command sets the address at 0x8014 from 0x3DB47A to 0x3DA932, which has now 'broken' the pointer to the VFT for the callback in tryatimer.

I've attached 'before and after' screenshots showing either side of this instruction, and the section from the timer.asm file where I think this is happening.

Best of luck with your further investigation,  thanks again,    Julian.

3660.Stack problem screenshot 04 before.rtf

5852.Stack problem screenshot 05 after.rtf

;----------------------------------------------------------------------
; 283 | gSlowTimers[i].Touch();                                                
;----------------------------------------------------------------------
        MOV       AL,*-SP[3]            ; [CPU_] |283| 
        MOVL      XAR4,#_gSlowTimers__Q2_6Timers26__N_10_timers_cpp_abad4d89 ; [CPU_U] |283| 
$C$DW$837	.dwtag  DW_TAG_TI_branch
	.dwattr $C$DW$837, DW_AT_low_pc(0x00)
	.dwattr $C$DW$837, DW_AT_name("___vc__Q2_5Array65CArray__tm__51_Q3_6Timers26__N_10_timers_cpp_abad4d8910cSlowTimerFUi_RZ1Z")
	.dwattr $C$DW$837, DW_AT_TI_call
        LCR       #___vc__Q2_5Array65CArray__tm__51_Q3_6Timers26__N_10_timers_cpp_abad4d8910cSlowTimerFUi_RZ1Z ; [CPU_] |283| 
        ; call occurs [#___vc__Q2_5Array65CArray__tm__51_Q3_6Timers26__N_10_timers_cpp_abad4d8910cSlowTimerFUi_RZ1Z] ; [] |283| 
$C$DW$838	.dwtag  DW_TAG_TI_branch
	.dwattr $C$DW$838, DW_AT_low_pc(0x00)
	.dwattr $C$DW$838, DW_AT_name("_Touch__Q3_6Timers26__N_10_timers_cpp_abad4d8910cSlowTimerFv")
	.dwattr $C$DW$838, DW_AT_TI_call
        LCR       #_Touch__Q3_6Timers26__N_10_timers_cpp_abad4d8910cSlowTimerFv ; [CPU_] |283| 
        ; call occurs [#_Touch__Q3_6Timers26__N_10_timers_cpp_abad4d8910cSlowTimerFv] ; [] |283| 
	.dwpsn	file "../timers.cpp",line 281,column 48,is_stmt
        INC       *-SP[3]               ; [CPU_] |281| 

Hi Julian,

Thank you for the additional details. I think I understand the issue better now and see what you are referring to. I have entered bug # SDSCM00042295 and it has been assigned to the compiler team for further analysis. As they analyze and have updates on the issue they will update the bug report, which you can track using the SDOWP link in my signature. I will also move this post to the compiler forum.

Hi Julian,

It seems that the compiler team is having a hard time debugging this issue as they don't really have a way to reproduce the issue on their device simulators and be able to debug the compiler itself. If they can't reproduce the issue to something that is runnable on their simulators, the problem has to be somehow narrowed down further. At the moment, from simply looking at the assembly code, a bug cannot be confirmed.

Can the project be cut down further in any way such that an analysis of the assembly code shows the problem, or so it can be run on a simulator? I do understand that a memory location is being overwritten when stepping through the code and do see it happening, however that isn't sufficient evidence to a compiler bug or that the value is not correctly restored at a later time. And since I haven't been able to actually run the code properly on a eZdsp either, it makes it even harder to analyze.

I don't think that simply looking at the assembly code shows the bug in this particular case. Do you agree? Can the problem somehow be further narrowed down? Please let us know if you have other suggestions to move this forward and we could continue to work this issue off-line (via forum private conversations) if needed.

OK, we're looking into putting together an EzDSP version.

Hi AArti,

    One of my work colleagues has come up with a build that runs on the 28335 evaluation board. This shows up the problem, too, so will be good for your guys.  However, he's having trouble uploading onto the forum (firewall restrictions on his UK site, we think). Could you give me a direct email we can send the files to?  Thanks,     Julian.

Julian,

I will send you a friend request and start a private conversation with you to share this information.

For reference, the code that runs on a F28335 eZdsp is attached. Details from customer:

The project sets up two timers. One timer is running is the main routine (this is working), and the other is set-up in Trytimer.cpp using the constructor CTryATimer::CTryATimer. This is not working.

Both implementations are identical. The timer itself is executing, but the ‘slow_timer_callback’ function pointer fails when executed outside of the main.cpp.

A printf has been added to:

void cTimerCallback::Callback()

{

      testcounter++;

      // Do stuff here to indicate the timer matured.

      printf("Timer callback is working in tryatimer.cpp\n");

}

cTimerCallback::Callback should execute if the timer was working correctly and this is demonstrated by the working timer running in the main.cpp

Working timer in the main.cpp:

void cSlowCallback::Callback()

{

      // Do something here so we know the timer is working.

      printf("Timer callback is working in main.cpp %d \n",testcounter);

}

2703.4111.Timer2833forTI.zip

Julian, Peter,

We're still looking into this, but one comment/suggestion from a co-worker:

The code is using both printf and timers. C I/O (such as printf) is implemented by stopping the DSP so the PC can service the I/O requests. This could have unexpected affects on the timers. The suggestion is to remove all C I/O from the code and see if that changes the outcome.

Reply from customer since he is having trouble posting to the forum:

All I/O have been removed and the affect is the same. The printf was just added to demonstrate that in the main.cpp the timer is working fine and that it only fails when implemented in a class outside of main.cpp