Help: Misterious 8292 Bug

[the_undefined]

Hey,

I was just wondering if something like that ever happend to anybody before and there is already a solution to my problem:

What I did was looking at Kevin's Code an stealing the Interpretor Idea but I wrote different function (to make it work with dead raconing just for now) and changed gave the constants different names and so on.

Everything worked really good until I tried to add a CMD_DIFFTURN Command to my Library that was supposed to make one Wheel slower in order to turn (instead of reversing them against each other like my CMD_TURN function does).

But whenever I use CMD_TURN and CMD_DIFFTURN together my first Command (here CMD_WAIT) gets the VALUE 8292 instead of 1 (#define CMD_WAIT 1). All other Values stay untouched. I was tring arround for nearly the entire day and couldn't figure out why and HOW something like this could happen, but what I found was that this number 8292 is appearing 2 times in the Assembler code which made me somewhat confused ...

So my question is did anybody else experience something like this before (maybe with another Value then 8292) or did I discover a new bug / way to trick myself ...

Ah and before I forget, I was testing this code withthe EduRC.

#define ROBOT_SPEED			10
#define DRIVE_TIME			2000
#define TURN_TIME 			1200
#define TURN_SPEED			20
#define TURN_DIFF			10

struct commands command_list[] = { 
/*Command              parm 1     			parm 2   					parm 3   */
{CMD_WAIT, 		       5000,      			0,       					0},						
{CMD_DIFFTURN,         TURN_TIME,          	TURN_SPEED,   				TURN_LEFT * TURN_DIFF},	// Time, Speed, Direction/Drift
{CMD_DRIVE,            DRIVE_TIME,          FORWARD * ROBOT_SPEED,   	0},							// Time, Speed/Direction
{CMD_DIFFTURN,         TURN_TIME,          	TURN_SPEED,   				TURN_LEFT * TURN_DIFF},	// Time, Speed, Direction/Drift
{CMD_DRIVE,            DRIVE_TIME,          FORWARD * ROBOT_SPEED,   	0},							// Time, Speed/Direction
{CMD_TURN,             TURN_TIME,      		TURN_LEFT * 20, 			0},	
{NULL,                 0,         			0,       					0}

};

[Mark McLeod]

We need to see more of your code to help locate the problem.

Offhand I'd say you might have an address mapping problem in your code caused by an argument mis-match for instance.
A decimal 8292 could be coming from a mis-mapped ASCII text string of "space@", or any of a number of other sources.

[the_undefined]

Okay, here is the source code. If anybody see's what I did wrong that would be really awesome for me. I'll be sry if you'll find out that my mistake is obvious but its the first time I do microchip programming. Anyway, thx to everybody that'll look at it ...

Felix

[Mark McLeod]

I took a quick look and repeated your problem.
It doesn't seem to have anything to do with the CMD_WAIT, because it happens with all NULL cmds as well. Oddly enough, it only happened for me when the number of commands equaled 6 or 7. More or fewer commands didn't have a problem. That's probably because the number of cmds determines the location where the array gets allocated. A quick solution is to pad with NULL cmds as a work around to go on with your testing until the problem is solved.

I'll take a look at the corresponding memory map for the problem and see if there's a space allocation issue or memory overwrite from the variables before it.

Found it. Your problem is line 15 of robot.c
A printf cannot have a format string of more than 80 characters (between the quotes). What's happening is the print buffer is overwriting memory locations that follow it. Depending on how many commands you have in command_list (the length of the array in other words) the linker will fit it in to the most convenient available space. Sometimes this falls after the print buffer. Several other variables are being overwritten as well, you just didn't happen to notice.

[the_undefined]

Originally Posted by Mark McLeod

I took a quick look and repeated your problem.
It doesn't seem to have anything to do with the CMD_WAIT, because it happens with all NULL cmds as well. Oddly enough, it only happened for me when the number of commands equaled 6 or 7. More or fewer commands didn't have a problem. That's probably because the number of cmds determines the location where the array gets allocated. A quick solution is to pad with NULL cmds as a work around to go on with your testing until the problem is solved.

I'll take a look at the corresponding memory map for the problem and see if there's a space allocation issue or memory overwrite from the variables before it.

Found it. Your problem is line 15 of robot.c
A printf cannot have a format string of more than 80 characters (between the quotes). What's happening is the print buffer is overwriting memory locations that follow it. Depending on how many commands you have in command_list (the length of the array in other words) the linker will fit it in to the most convenient available space. Sometimes this falls after the print buffer. Several other variables are being overwritten as well, you just didn't happen to notice.

Wow! Thank you so much ... I would have probably commited suicide at some point because changing the line 15 would have really been the last thing I would have concidered ...! Thank you! Thank you! Thank you! That made my day!

And regarding prinft: Is it 80 chars / cycle max or 80 chars / fct call max? Just so I know which limit I got. After that I'll write an Error Handler in the printf class when the string exceeds the 80 sign max ...

And one more time, thx!!

Felix

[Mark McLeod]

Originally Posted by the_undefined

And regarding printf: Is it 80 chars / cycle max or 80 chars / fct call max? Just so I know which limit I got. After that I'll write an Error Handler in the printf class when the string exceeds the 80 sign max ...

Per printf call.
You can break up that printf of yours into two printf's and it will work fine.

The print_lib.c file has this lurking warning as part of the lead comment block:

* 3. The %s directive only supports a string of 40 bytes and the format string
* may not exceed 80 bytes. The sprintf routine is not included. Keep in 
* mind that the stack size has a 256 byte limit.

That's the safest idea, to modify the IFI printf code to add a check for strings > the limit. We simply truncate the string if it's longer than ifi_printfBufr.

[the_undefined]

Originally Posted by Mark McLeod

Per printf call.
You can break up that printf of yours into two printf's and it will work fine.

The print_lib.c file has this lurking warning as part of the lead comment block:

* 3. The %s directive only supports a string of 40 bytes and the format string
* may not exceed 80 bytes. The sprintf routine is not included. Keep in 
* mind that the stack size has a 256 byte limit.

That's the safest idea, to modify the IFI printf code to add a check for strings > the limit. We simply truncate the string if it's longer than ifi_printfBufr.

Ok thx again for this additional information. As I said I was completly unaware that printf can get me into such trouble so I didn't pay enough attention to the comments in the class. For the next "misterious bug" I'll read the comments in the included classes/functions first ... : )

Bye

Felix