Function (header) and halting problems

UP

Anyone knows what can be happening to me?

Hi,

    AFAIK, there is a wiki regarding creating new CCS projects. Search the CCS forum. Here are some links below, that I think, may help you.

   http://software-dl.ti.com/sdo/sdo_apps_public_sw/CCSv5/Demos/GSG_Creating_projects_v5/GSG_Creating_projects_v5.html

  http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/p/263086/919971.aspx#919971

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

-kel

About the project, I did everything cointained in the guides I found, and in fact the project builds if I don't put some functions that are causing problems. The point, as it seems, is that the compiler doesn't find the functions even tough they're declared on the headers above the code. Ever had this problem?

Many problems there. I've no direct experience with Stellaris or Tiva. Just a few comments to get you along until more knowledgable people can comments.

Including the header (.h) file is not sufficient to include the code into the project. You either have to add the implementation (.c) file to the project or include a library with function. For SysCtlClockSet(), I believe that is part of the driver library. called something driverlib-xxxx.lib Check the example project settings and see how they pull in this library. Apply those settings to your project.

As for stopping the processor, I am guessing some examples do have a loop foever loop at the bottom of main(). That means "main()" exits to ... nothing and there is no code to stop and display. Don't know about the "Trouble Halting" problem.

Thank you, it was the library. I included it and the project stopped showing errors ^^

About the infinite loop in the example projects, they do have, as the project usually initializes the peripherals and enter a "while (1)" code". Still, aren't they supposed to stop when I press the button to stop debugging? I tough about the "Trouble Halting" problem, that could be preventing the device from being stopped.

The problem appeared again, after I added the library. Now, the compiler doesn't understand a function called on a header I made on the PinMux software. I thought about the library but didn't find one.Do I have to download it separately? 

Here are the images of the problem:

Where is rgb_pwm.c located? Put rgb_pwm.c in the same directory as main.c for the project pwm_test. Code Composer will automatically add ALL files in the project directory. Otherwise you have create your own libraries and pull them in the same way as the driver.lib. For now, I suggest put all you own code in one directory.

As for the "Trouble Halting" problem, I've seen it on processors where they just get into a state where they don't listen to the JTAG any more. Never quite been able to figure it out why. The "while();" loop should hold the processor in a state that can be halted. That's all I got. Hopefully some Stellaris/Tiva Experts can comment. I am surprised they haven't.

Norman Wong said:

Hopefully some Stellaris/Tiva Experts can comment. I am surprised they haven't. 

Not that I so qualify - but not everyone here uses CCS - prefering other more established IDEs.  And - it is Saturday...

Poster has somewhat created his fate by the (perhaps unwise) desire to, "create own project."  Many things must go exactly right for that to work - and may work incompletely - even then.

KISS advises to search/find "closest factory supplied" project (insures all libraries/linkages - present/accounted for) and then add user custom code therein.  The goal should be learning/mastering the MCU - not becoming IDE savant...

Again, thank you, putting the header in the same directory solved the problem. Let's see if during the week some expert can solve the halting problem ;)

About the creating own project, I think it should be natural - is it too hard to do? I'm not trying to be a "IDE savant" as you refer too, I just don't want to become a prey to every error I find ^^

Jéferson Guimarães said:

creating own project...should be natural - is it too hard to do?

Apparently so - several hundred posts - this forum/others confirm.  (for every poster - suspect far more suffer in silence)

As stated - getting everything, "just right" proves challenging - demands great attention to detail - and may make unfair assumptions about new users' skill/experience/diligence...  To further complicate - IDEs frequently expand/shift - which may invalidate certain critical, past, written guides.  (not to ask - "how" I know...)

Add to this - fairly recent MCU "rebrand" - new model flood - does this sound "natural?"

Indeed IDE mastery is nice goal - but perhaps achieved, "more naturally" by your use of "tested/verified existing" projects - to which you add your custom features/functions.  Suspect that this will immediately boost your MCU productivity - freeing it from its present, "IDE hostage" status...

Note that our group offers this guidance to all new hires/interns/contractors - it is an accommodation to, complex IDE "reality" - and our desire to deliver some MCU-based product on time...

Good luck... and KISS...

 btw - find your writing outstanding (well organized, inventive word choice, nicely considered)

UP

Any ideas about the halting problem? The projects seem to be running well here, only this problem so far.

cb1- said:

 btw - find your writing outstanding (well organized, inventive word choice, nicely considered)

Thank you haha

When you first download your code, CCS should put you at the top of main() and stop. Can you step from there?

Hi, sorry for the delay to answer.

Yes, I can step from there. I can go line by line on the code till I get the errors I mentioned before. It appears that even after the libraries are added, the code still can't find some functions on the headers. Also, this code (mine) shows the "Trouble Halting" problem when I try to pause, and don't work properly (although this can be my fault):

A note about stepping through code. Sometimes you cannot step into code in a library. If that code is not compiled with debug information, source code will not be available. The function is there as binary opcodes. Just no C source. You will get disassembly of opcodes in memory. Best to step OVER those functions.

As you are stepping from the top of main(), at what line does it "Trouble Halting"?

The trouble halting problem doesn't appear while stepping through the code, it appears when I put it to run by itself and try to pause. Also, if I tell the code to stop, it simply doesn't.

Reading between the lines, I am guessing that stepping through the code is okay until you try to step on line "while(1);". I would hazard to guess that the loop should do some like increment a volatile variable.

In fact, the trouble starts when I get to the While (1), but happens speciffically in the likes of SysCtlDelay functions (although they appear before inside functions called from the headers). As I keep stepping, I enter the SysCtlDelay function and execute the codes, but when I'm about to step to the next line, the debugger start showing errors and don't stop.

As work-around, try stepping over library function like SysCtlDelay() rather than stepping into them. Perhaps you should start another thread with the one problem of "Unable to step through a library function with no source". Usually you can step through the disassembled opcodes from memory, one assembly instruction at a time.

Perhaps start another thread with "Unable to break in while(1);". I am guessing the processor is not doing any memory accesses and is in a tight loop from instruction cache. Try incrementing a variable like so:

volatile int dummy;

while(1) dummy++;

I tried putting the variable and it worked fine, I made a video to help understanding:

http://youtu.be/Gl7xeVM7sXA

If needed be, I can make another with more information. As you may see, everything seems to be working fine, except for the errors on the delay and the inability of the debugger to stop the MCU from running the code. Should I make a new topic about these two problems?

From what I can see in your youtube video, I can't see anything that looked bad.
- You can step over SysCtlDelay(SysCtlClockGet()*3/3);
- You can step into SysCtlClockGet() and step though it with proper  C source displayed.
- You can step into SysCtlDelay() and step though it abeit in assembler. If you look at the sysctl.c source, this is a function written in assembler consisting of only 3 instructions:
SysCtlDelay:
  subs r0, #1
  bne.n SysCtlDelay
  bx lr
it just a loop that counts down to zero. The register r0 is passed in and has the initial value of SysCtlClockGet()*3/3. If you stepped long enough, eventually it would return. Easiest just to step out.
- The video did not appear to show a "Trouble Halting" problem. I might have missed it.