This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

F28335 strange runtime behavior

Hi,

I´m using a F28335 developement kit  and CCS 5.4 for my bachelor thesis, but the controller have a runtime behavior that I absolutly cannot understand and makes me impossible to work with. I hope someone could help.

i´ve wrote my own code and have to decide in the debug mode that the controller do things that absolutly transgress against any programmers logic. At this really simple code lines the controller did following.

******************************************

int count;

int done;

*****************************************

If(count>=20)

{

done=1;

}

********************************

I stepped me step by step in the single step debug mode through the program and looked in the watch window and see that the integer count has the value 0. The controller checked the if condition and go into the brackets and set done=1; . I can´t understand why the controller ignores the condition and set the variable. But it´s not a constant failure. This and Some other if conditions with more complex conditions work sometimes right and sometimes not.

First i thought that I´ve made mistakes at the initialisation and configuration of the controller and so i´ve studied the students Labs for this controller. I´ve took the Lab for the interrupt system und followed the instuctions step by step for creating a CCS project and so on. But here, where i nothing did anything self, i found other mysterious behavior too. When the controller goes into the interrupt routine, the line to reset the acknowledge bit at the end of the routine doesn´t work at first time. The controller work the line but the bit wasn´t set. And so the interrupt routine run throught many times. I´ve implement a counter to see how many times the controller takes, to set the bit and reset the acknowledge. I decide that it is not constantly. Sometimes it takes 2 cycles , sometimes 4. befor the controllers set the bit and reset the interrupt acknowledge to work the normal code.

At other modules there are strange failures too. Sometimes the ADC works correctly and sometimes it shows the ADC value 156 independently from the input voltage.

Another thinking was, that the controller was broken. But i tested a second controller which was bought at the same delivery. And this one shows also strange behavior. Many strange things the controller do, aren´t constantly. For me it looks really arbitrarily and i can´t explain myself the hidden logic behind. I´ve no idea what kind of problems exist. But with so massiv failured runtime behavior I cannot work with the device which I immediatly need to finish my studies.

I hope that someone could help me, or had the same problems like me and know more about it.

best regards,

Nils Gang

  • Hi Nils,

    What´s your optimization level? (Properties/Build/C2000 Compiler/Optimization)

    If your optimization level is agressive, what you debug step by step is not what you code;)

    Hope this helps

    Alex

  • Hi Alex, thanks for youre answer.

    The optimization level wasnt the problem, there was nothing selected.

    It seems that i´ve found the failure source. Everything works right when i didnt use the TI function InitSysCtrl() (found in DSP2833x_SysCtrl.c )

    But i want to know what could cause such a strange behavior in this function. i have no idea.  If someone could imagine whats the problem, please explain me.

    thanks

    Nils

  • No idea why you encounter these problems, but your workaround seems to point to a not correctly initialised controller.

    • Setting PLL and flash settings (etc) is mandatory. You cannot expect a running  controller without setting these things.
    • A simple if(check) with one assignement will be translated into a conditional move instruction.
      So the debugger will show you that it moves to the line with done=1, but done will not be set to 1. Step through dissassembly for cleared action
    • Are you sure you are connected by JTAG with with the controller (I've seen persons connected to a simulator instead of the target...)

    I suggest that you take a example program from TI and let it run for tests.

    Good luck!

    Roger

  • Thx Roger,

    The problems came from the PLL settings. Then there were wrong settings  to the high speed peripheral clock, so the moduls like the ADC can´t work rightly. Since I configured it the controller work without problems :)

    thanks

    Nils

  • Thank you for your feedback!