sprintf bug?

pmuldoon · Joined: 26 Sep 2003 Posts: 218 Location: Northern Indiana

compiler: 5.074
chip: 18F67K40

I have a strange bug in some rather complicated code.
I've narrowed it down and can make/break it by changing an sprintf() statement.
I have a uint32 variable that I am writing to a buffer, and if I use the %ld format it works fine, even though it's unsigned. If I use the %lu format it seems to somehow avoid executing some code.
Can anyone make sense of why the compiler would use a BRA instruction instead of a CALL in the .lst output?

I know I'm probably a rev or two behind. I've requested a maintenance update, but sometimes that takes a while.

here is the %lu version:

compiled with %ld

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

If a routine is called only once in a program, the compiler will often do a BRA
to the routine, and then another BRA back to where it was "called" it from.
This is done to save a stack location.

If you want help on this, you should post a very small but complete test
program that is compilable without errors.

pmuldoon · Joined: 26 Sep 2003 Posts: 218 Location: Northern Indiana

Thanks, PCM. I didn't know that.

I'm trying to sort out a bug and changing the sprintf resulted in the exact same symptom. I must be looking in the wrong place. Just not exactly sure what I'm looking for, yet. I'm suspecting it has to do with signed and unsigned int32's.

Is there any way to know if the last few compiler updates that I missed relate to this chip? I looked around on the website but couldn't find anything like a compiler rev history.

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

Here is the version history:
http://www.ccsinfo.com/devices.php?page=versioninfo
But they often make changes that don't get listed in the versions page.

Ttelmah · Joined: 11 Mar 2010 Posts: 19546

As a general comment, the commonest problem with a sprintf, would be not enough space for the output. Remember the trailing \0. An overflow of the target buffer could cause all sorts of oddities.

pmuldoon · Joined: 26 Sep 2003 Posts: 218 Location: Northern Indiana

That was one of my first thoughts too. but the buffer is 80-bytes and longer strings print out without a problem. (it sure seemed like buffer overflow clobbering another variable)

I'm gonna do some things (set flags/ print variables) to try and narrow down where things are going wrong. I just thought for sure I found something that was closely related because just changing the format from %ld to %lu would make or break it.

Sorry I can't give you more info, but it's a bit complicated and would take a while to write out clearly. If I can't corner it soon I will write up a test program and post it.

Thanks,

Ttelmah · Joined: 11 Mar 2010 Posts: 19546

Try with a fractionally shorter length for the output. Wondering if something in the printf is overflowing at 10 digits. I know an int32 can give ten digits, but it might be a mode that isn't expected!...

pmuldoon · Joined: 26 Sep 2003 Posts: 218 Location: Northern Indiana

Excellent thought (it didn't fix it, but worth a try). That would've been exactly the kind of thing I would have hoped to find.

I'm making some of my key local static variables global and printing them out to see the process better.. I already see something that is totally wrong, just need to track down why. It's either me or the compiler - probably me, but I should figure it out soon.

Ttelmah · Joined: 11 Mar 2010 Posts: 19546

Good Luck.. Smile

One thought any possibility of an interrupt event occuring during the print changing something?. For instance if the value being printed was updated in an interrupt I'd be looking at copying it into a local temporary copy before printing. Can you test if the actual print works OK without the other code?.