TMS320F28335: SYS/BIOS v6.46.6.0 and XDCTools v3.31.3.43: Running code in debugger works ok on my computer but does not work ok on co-workers computer

Is it the exact same .out that you're running on both computers? Or are you both importing and building the project independently? If it's the latter, is there a difference in compiler version being used?

Whitney

Hello Whitney,

I am using CCSv9.3.0.00012  and he is using CCSv6.2.0.00050.  Both of us are using the same compiler (C2000 v16.9.1.LTS)

I think we are also using the same debugger (XDS100v2).

I sent him both my code and the out file, however, I am not sure if he is using my out file while debugging.  I will make sure he debugs with the out file I generated.

I was able to successfully able to debug with CCSv6.2.0.00050, however while debugging errors started to show up in the problems window.  The errors indicate that compiler/CCS didn't understand some of the c++ code.  The errors did not hinder me debugging the code.

Stephen

Thanks for the additional info. Let me know what you find out about which .out he was using.

I can't think of anything in the CCS debug tools that could cause that kind of behavior. I assume the issue is happening regardless of whether or not there are breakpoints set in the code?

The application uses SYS/BIOS? Can you use ROV to look for errors? Signs of stack overflow?

Whitney

Hello Whitney,

I am having a stack overflow on my setup now. 

Maybe I should give you more background information. 

I created an application and now my colleague is testing the CAN protocol communication between a display and the main board. 

I don't have the display hardware setup to test the communication, so (just recently) I created some stubs in the code to emulate CAN messages.  After doin so, I started having a stack overflow that occurs approximately 6.5 seconds after reset.

I am not able to determine what is causing the stack overflow.

The application code only has following items: Two Task and three ISRs (two timer and one pin interrupt) 

The stack overflow occurs (6.5 seconds after reset) even after I do the following.

1. I removed all tasks except the idle task

2. I placed a return at the beginning of the timer ISRs.

Do you have any ideas what to check next?  Could this be an idle task issue? 

Stephen

Does ROV give you any hints as to where the stack overflow is occurring? Is it the system stack or one of the task stacks? Does increasing the stack sizes help or does it seem like there's a buffer that's overflowing somewhere that is eventually running into the stack?

Whitney

Hello Whitney,

Ok, I am not getting the stack overflow anymore, but my co-worker is.

I run the program over and over on my side and I don't get any stack overflow.  I did make some changes to the Sys/Bios configuration, but I can't exactly remember now what all the changes were.  I think I removed the task and recreated them.

A spreadsheet containing the BIOS errors from my co-worker's debug session is attached below.

Stephen

bios.xlsx

Glad you were able to solve your stack overflow. It looks like in your colleague's case the memory is getting corrupted to the point that even the objects that ROV pulls it's info from are invalid. What has he done to attempt to solve it? Increasing stack sizes? Does it still appear to be tied to the memset function?

Did you determine whether or not you were running the exact same .out? Like if you run the .out that's giving him memory corruption issues in your CCS setup, do you see the same?

Whitney

Hello Whitney,

Some background:
I took someone else code that seemed to run ok: no stack overflows and no weird debugging issues. The Original code had 3 HWIs, SWIs and no Task.
The HWIs consisted of two timer isrs and 1 gpio interrupt. I converted the two hwi timer isrs to timer module c28 timers. I also added two task.
The new program worked ok when running on my board, however, the debugger acted strangely on my co-worker's board.

Current Status:
I found out that the weird debugging issues that my co-worker was having is related to the a difference in FPGA firmware (the board has an FPGA and a TMS320F28335 uC). The FPGA firmware I was using is completely different than my co-workers. The FPGA and uC are connected, so the issue might be caused by the uC and FPGA pins being configured as an output and that might be causing issues with the board.  The problem with that hypothesis is that the original code did not have any of the issues that my co-worker experienced.

Therefore, I have decided to go back to the original design of 2 HWIs timers instead of two timer module c28 timers.

The issue I am having now is:

Description Resource Path Location Type
gmake: *** [build-21490655] Error 2 Alpha1 C/C++ Problem
gmake: Target 'all' not remade because of errors. Alpha1 C/C++ Problem
gmake[1]: *** [build-21490655-inproc] Error 1 Alpha1 C/C++ Problem
ti.sysbios.family.c28.Hwi.Instance#2 : Hwi 35 already in use (by &XINT1_ISR). .xdchelp /Alpha1 line 262 C/C++ Problem

What is XINT1_ISR being used by?

There isn't any TimestampProver defined in the configuration file, i.e.

var TimestampProvider = xdc.useModule('ti.sysbios.family.c28.TimestampProvider');
TimestampProvider.timerId = 2;

Therefore,  I am not using the TimestampProvider. Is that correct?

I also set the Clock tickSource to Timer 2 as shown below. therefore, the timer tick should be using Timer 2.  Is that correct?
Clock.tickSource = Clock.TickSource_TIMER;
Clock.timerId = 2;

Please see attached configuration file below.

What is the purpose of

var ti_sysbios_family_c28_Hwi0Params = new ti_sysbios_family_c28_Hwi.Params();
ti_sysbios_family_c28_Hwi0Params.instance.name = "ti_sysbios_family_c28_Hwi0";
Program.global.ti_sysbios_family_c28_Hwi0 = ti_sysbios_family_c28_Hwi.create(35, "&XINT1_ISR", ti_sysbios_family_c28_Hwi0Params);

Why doesn't it do the same thing for the other two HWIs?  Why is the HWI related to XINT1_ISR so special?

Stephen