loader_exit does not contain frame information

Rick,

I might sound strange, but this is actually normal behavior. The loader_exit function is linked into your application though an optimized SYS/BIOS (or XDCtools) library. When BIOS terminates (for some reason) it will eventually call loader_exit() and then sit there because of a hardware breakpoint I presume.

Did your application call BIOS_exit() by any chance?

Hey Tom:

The program never really starts.  It seems to crash before it even gets out of the gate.  Typically, I see a break point right after main().  In this case, no.

There is no call to BIOS_exit(). 

I'm going to start anew on this.  I started with an empty Ti-RTOS shell.  I'll try it with a little more this time.  I fear that I might not have added or included something properly.  I'll also see if you have any other thoughts.

Thanks

Rick

I've got a "hunch" on what the problem may be (I ran into this before myself).

Can you verify that after you loaded the application (hitting the debug button) that it get's stuck in loader_exit? Can you then see if your application runs after performing a System Reset (not a CPU reset), a restart and hitting run?

Hey Tom:

Found something weird....

In "Task" under the ROV I found...,

0x200075c0,ti.sysbios.knl.Task.IdleTask,0,Ready,ti_sysbios_knl_Idle_loop__E,0x00000000,0x00000000,

124,4096,0x20002360,n/a,n/a,

was running an Invalid Mode... I've been commenting out code and it just started running. 

Give me a bit to track this down.  The line above it OK.  I should have captured it when I first saw it.  Need a bit of time.

Rick

Hey Tom:

I have the issue narrowed down to how I am setting up a Task.

Something is screwed up with it.  I should be able to figure this out fairly quickly.

By the way, I saw your answer a comment about a UART readTimeout... 

That was REALLY bugging me until I saw your explanation... Thank you.

I'll let you know what I did wrong.

Thanks

Rick

Hey Tom:

I have this narrowed down to 1 line of code in a Task.

I am focused on the startup behavior of the program.  IE what happens when I hit the green Debug ICON and NOTHING else.

Line of code:

sprintf(szMsg, "Sending Attempt:");

Stack Size: 8192

Without Sprintf....

*This looks like a good start up.  I'll have complete control over debugging.  No issues.

Using Sprintf...

The weird thing about this is simply that the program never seems to start.  Or the Start is somehow messed up.  This is not normal.

Hope this makes sense.  Any thoughts?

Thanks

Rick

Tasks haven't started execution until BIOS_start() is called, which gets call some time after main(). This means that sprintf() shouldn't have been executed if it's called in a Task function.

I'm wondering if this is more of an issue of enabled breakpoints (as there is a hw breakpoint used to run to main()). Can you disable all the breakpoints? Also, does this only happen immediately after pressing the green DEBUG icon?

After you pressed the green debug icon and are sitting there running, could you try the steps I posted earlier?

1. Halt the target
2. System reset
3. Restart
4. Run

I'm suspecting this a loader problem and I just want to see if this workaround works for you. If it does, I need to submit a bug to get this fixed, otherwise something else is going on here.

Are you getting any sort of messages in the CCS console when you press the debug icon?

Hey Tom:

I cleared all of the breakpoints.

This only happens immediately after hitting the green Debug button.

Attempted to try the steps above...

The "Chip" ICON, is not active when I try to do a System Reset.

This might sound a little silly; but, how do I Halt the Target?

I have the Task boiled down to this...

Void Task_UART_Rick(UArg arg0, UArg arg1)

{  

int iCounter = 0;

char szMsg[128];

sprintf(szMsg, "Sending Attempt: %i", iCounter); 

}

Almost everything else in the program has been removed.

Let me know if there is anything else that I can try.

Thanks

Rick

Hey Tom:

One more thing...

This morning, I re-created the project fearing that I corrupted something or generally screwed something up that I wasn't noticing.

I substituted sprintf for ltoa & strcpy & strcat....   Everything worked perfectly, I even got the UART_write to work as desired. 

As soon as I inserted the sprintf back into the Task, the problem came right back.  I can't do a CPU or System Reset because the ICON is not active.  Break points do not work.  Etc...    As soon as I took sprintf out, all was well again.

At this point, I'm inclined to agree with you....  I think there is a bug somewhere.  Let me know what I can do to assist.

Thank you for all of your help.  I will be more than happy to hit the Verify button once I hear back from you.

Rick

Rick,

the idea behind the GPIO driver is to hide away the need for the user to have to create the Hwi.

Essentially, the driver creates one Hwi with a function pointer "GPIO_hwiIntFxn()" for a given GPIO port. This function in turn will call perform a callback for every pin on that GPIO port for which the interrupt flag was set. If you wish, you could also install your own Hwi function for a given GPIO port; without using the GPIO driver on that given GPIO port.

If you end up diving into the TI-RTOS drivers, they all will have a Hwi_create() in the DriverTiva_open() call (if they use interrupts).