SYS/BIOS and Sprintf

Which version of SYSBIOS are you running?  Also could you let me know the XDCTOOLS version?

If you have a *.cfg file, if you could post here also.

Judah

Judah,

I'm using sys.Bios version 6.33.4.39 and XDCTools version 3.23.2.47.

0842.app.cfg

The cfg file is attached.

Thanks for your help.

Ed

One wild guess is that sprintf() requires a lot of stack and that you are overflowing your stack.   Can you try using ROV and look at your stack usage before and after the call to sprintf().   Adding the Semaphore_pend() call probably changes the timing but the issue is still there.   The stack usage might be on the harry edge and an interrupt at just the right time when within sprintf()'s max stack point, might cause the stack to overflow.    Note that we save some context on the task stack before switching to the ISR stack.

-Karl-

Kari,

I don;t think this is a stack issue.  I did a quick test and doubled the stack size for that task from 1000 to 2000 and it made no difference.

Ed

Can you post your *.out file here (I'm talking about the one that crashes)? Is it something that I can run on a TMS32028335 board? Your not running this on your own unique board are you?

Judah

Judah,

The software is running on a custom board, but it should be able to run on just about any TMS320F28335 board, the only catch is that I using a RS-232 port connected to SCI-B.  Do you have a board that has and RS-232 port on SCI-B?

Ed

No, i don't think I have a board with that.  If could reproduce with the print just to stdout/console window I could help otherwise, not sure what it is.

Judah

Hi Ed --

Is the output to UART required to make this fail?   Can you just add the sprintf() code and stub out the UART to see if it still fails?  I'm trying to see if the problem is sprintf() or sprintf() interaction with UART code.

Is your UART ISR written in C or assembly code?   You should use the BIOS dispatcher to save/restore context.

Can you try changing your sprintf() to format an integer instead of a float to see if the problem relates to floating point operation somehow?

This problem is very strange and not sure what could cause it.

Regards,
-Karl-

One more thing ...

Can you also check your ISR stack usage?   You can see ISR stack in the Hwi module ROV view.

Karl,

Thanks for the response and yes this is a very strange problem.

I did confirm that it is the sprintf statement that is causing the issue.  I removed just about everything from the routine except for the sprintf and the probelm persists. 

The problem only occures when using float values.  I had been using this routine for some time with intiger values without issue.  Only when I started using the float values did things go wrong.

All my code is written in C, including the ISR for the SCI port.

Lastly I checked the hwi stack usage in the ROV and is't way below the limit at 223 with a stack size of 2000.

Hope that points to something.
Thanks again for your help.

Ed

What does your sprintf() function call look like?

Are you passing the float argument to sprintf() properly?

Are you using the C runtime 'sprintf()' or the xdc runtime 'System_sprintf()'?

If you're using System_sprintf(), you have to enable floating point conversions in your config file by adding the following statement:

var System = xdc.useModule('xdc.runtime.System');
System.extendedFormats += "%f";

Alan

Alan,

I'm using the runtime sprintf() (see below). 

sprintf (tx_String,"Temperature = %5.2f   ",temperature);

Good to know about the System_Sprintf() however.  Where do you add the statements you indicated?  (I'm using the graphical tool for the config file.

Ed

I'd like to recreate the problem locally to effectively diagnose it.

Can you provide a minimal testcase that demonstrates this problem?

Alan

Alan,

Not sure what information you need.  Would it help if I sent you the cfg file? 

Ed

I'm hoping you can provide a simple test.c and test.cfg file with only the code necessary to recreate the behavior.

If not, I can try to recreate it based on what you've described so far.

Alan

Alan

Sorry for taking so long to respond to your posts.  My emails from E2E were being movving to the junk folder for some reason. :-(

I had a look at the stack early it it did not seem to be an issue, But I will dig a bit more and get back to you.

Ed

Alan,

You were right it was a stack issue.  I was looking at the wrong stack.  I was looking at the HWI stack when I should have  been looking at the task stack.  You are right that the sprintf with the float was pushing the stack over 1000 which was my size of the task stack.  I doubled this stack and the issue went away.

As I size note, I did have a look at this stack in ROV but it didn't show that the stack overflowed.  It was only after I increased the size of the stack that I could tell that it was overflowing the old value.  Is there a way tell if a stack has overflowed?

Thanks

Ed

Fantastic!

The Task "Detailed" view shows how deep the stacks have been and whether they've overflowed.

The "Basic" doesn't show this.

Alan

Alan,

I was looking at the detailed view.  This was after the system had crashed however.

Ed

Hmm.

Hopefully you do not have either of these in your config file:

Task.checkStackFlag = false;

Task.initStackFlag = false;

This would inhibit overflow checking in ROV.

Alan

Nope, both are true:

If you're willing and able to reproduce the original symptom, please post a snapshot of the detailed task view after the crash.

This should have worked.

Alan

Sure,  the first screen capture is before the crashm, the second after.  Some value do show up in RED and the task does show as blocked, but the stack is still below the size.

Ed

Alan,

Thanks for the explanation.

Ed