TMS320F28377D:Reason why timer stops

Hello,

Can you provide some more details about your application? Are you trying to run an example from C2000ware? How are you verifying that the timer has stopped? Which timer instance and period/prescaler configuration are you using?

Best Regards,

Delaney

Thanks for getting back to me.

The timer settings are as follows.

----------------------------------------------------------------------------------------------------------------------------------

var ti_sysbios_family_c28_Timer0Params = new ti_sysbios_family_c28_Timer.Params();
ti_sysbios_family_c28_Timer0Params.instance.name = "ti_sysbios_family_c28_Timer0";
ti_sysbios_family_c28_Timer0Params.period = 20;
Program.global.ti_sysbios_family_c28_Timer0 = ti_sysbios_family_c28_Timer.create(null, "&Timer20us", ti_sysbios_family_c28_Timer0Params);
var ti_sysbios_family_c28_Timer1Params = new ti_sysbios_family_c28_Timer.Params();
ti_sysbios_family_c28_Timer1Params.instance.name = "ti_sysbios_family_c28_Timer1";
ti_sysbios_family_c28_Timer1Params.period = 1000;
Program.global.ti_sysbios_family_c28_Timer1 = ti_sysbios_family_c28_Timer.create(1, "&Timer1ms", ti_sysbios_family_c28_Timer1Params);

----------------------------------------------------------------------------------------------------------------------------------------

The fact that the timer stopped was observed by outputting the process of the stopped timer interrupt to an external device and observing it on an oscilloscope.

The 20us timer executes the main process, and the 1ms timer does trivial processing.

It is always the 1ms timer that stops, while the 20us timer keeps running.

There are no rules regarding the frequency of occurrence. On average, it occurs about once every 13 hours.

Sorry for the clutter, but I need your advice.

Hello,

Thank you for clarifying. I will loop in the SYSBIOS expert for their input.

Best Regards,

Delaney

Are you able to look at the CPU Timer and PIE and IER/IFR registers to try to get a better idea of what might be happening?

What's the execution time of the 20us ISR? Is the CPU pretty heavily loaded or should there be plenty of time for the timer ISRs to execute?

Whitney

I tried to observe for IER, but when I changed the code, the event of Timer1 stopping did not occur anymore.

The maximum processing time for a task with a 20us timer was 11.2us. So we believe that there is a margin of processing time.

As additional information, changing the stack size from 2048 bytes to 512 bytes increased the frequency of timer stoppages.

However, both 2048 bytes and 512 bytes are more than enough stack size when checking the CCS Stack usage.

Currently, the stack size is changed from 2048 to 512 bytes, the 20us timer is woken up by RTOS, and the 1ms timer is changed to interrupt processing to see if the event is reproduced.

Please let us know if there are any additional details that need to be confirmed.

I know you said the issue happens somewhat unpredictably over a long period of time, but are you able to do some debugging? Like can you connect the debug probe after the timer stop has happened and use CCS to look at register states, view ROV to see the RTOS state, etc...?

If you don't know how to connect to a device without doing a reset and disturbing the device state, you can either follow the steps in this video or create a new .ccxml file and edit the settings to remove the .gel file and connect using that.

Whitney

Connect to debugging to see what happens when a reset occurs.

As additional information, I have confirmed that when Timer1 is stopped, the IER of INT13 is set to 0 and is not moving.

Kishi Masahiro said:

Connect to debugging to see what happens when a reset occurs.

Have you taken steps to avoid the reset? Like I mentioned in the previous post, one quick way to do this is to create a new .ccxml file with the .gel file removed. See the screen capture below--see how the "initialization script" field is cleared out?

It would be helpful to be able to connect so you can use ROV (Classic) to check the state of the Hwis, check for stack errors, etc...

Whitney

I have set up the debugger as you suggested and tried to connect it, but the following error occurred.

The debugger uses XDS200.

Are there any conditions, such as the need to use XDS560 to view it?

As shown in the image, the Initialization Script is blank.

Please let me know if there is anything else we should try.

Thank you for your cooperation.

Do you have any security enabled on the device that might be preventing the debugger from connecting? Can you also try toggling the realtime mode (see linked post below) setting to see if that makes any difference?

https://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/633710/ccs-tms320f28335-real-time-enulation-problem

Whitney

Despite trying different configurations, I'm unable to attach the debugger to the device while it's running.

How did you confirm earlier that the IER bit was being cleared? Toggling an IO? You mentioned that changing the stack size seems to make some difference in the code behavior. Can you try calling the Hwi_getStackInfo function and seeing if it's reporting any issues?

https://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/sysbios/6_83_00_18/exports/bios_6_83_00_18/docs/cdoc/ti/sysbios/hal/Hwi.html#get.Stack.Info

Whitney