Switch statement going to wrong case...

[DonWare]

Hi, I've been working on code for a PIC18F6527 with no problems. I'm using an int8 in a switch statement and constants numbered 1 thru 6 in the case statements. If I break at the top of the switch, I can see that the int8 = 3 but the code steps to the constant which = 4.

I've tried "clean" and "build all" and "make", deleted all but the C and h files.

Any ideas ? Thanks.

[Humberto]

Are you asking regarding C code? What if you post your code in order to understand your point.

Regards,

Humberto

[Wayne_]

Thats nice ;) Maybe posting the actual code will help us tell you what is wrong ? And, for this post the .lst segment for your switch statement.

It would be nice if there is enough code so we can compile it.

Also your CCS version number would be useful.

[SherpaDoug]

Do you have a break statement so when it finishes case #3 it doesn't go on to case #4? That is a common error in switch case statements.
_________________
The search for better is endless. Instead simply find very good and get the job done.

[DonWare]

Yes this was in C and I had break statements. For now, as best I can tell, removing a call to another possibly un-needed routine during the init got rid of this problem. Something was getting clobbered. I simplified the switch statement as much as possible and still had the problem. Not sure what it's about yet but I don't have time to look into it right now.

Thanks for the replies.

[Wayne_]

So you are still not going to post it. Do you want us to help ?

[DonWare]

For now I'm going to let it sit. Like I said, I may not even need the part of code that seems to be causing the problem.

So no I don't need any further help for now. Thanks.

[MikeW]

Donware,

that's an extremely selfish, and bad attitude.

You ask for help, people try to help, and then you say

"So no I don't need any further help for now, thanks"

I would suggest you dont ask me for any help in the future !!!!

Mike

[DonWare]

Geez are you kidding ?

The reason I'm not going further with this is because I'm in a hurry to do other things and this may not turn out to be a problem anyway. So why waste everybody's time ? I'd love to know the answer but I just don't have time right now.

I'm sorry I didn't post extensive code in the first message. I know how frustrating it is to try to help somebody with minimal information. I get that all the time at work here.

That's the only constructive thing I can say.

[MikeW]

I refer you to my previous post


obviously, my standards are different to yours.


Mike

[meereck]

// OT START
// I don't think that posting a part of .lst file takes too much time and effort.
// The knowledge of potential compiler bug might be useful for all of us including CCS.
// OT END

[Wayne_]

[SET]

I used to get problems like this, although I think it was with pretty old versions of the compiler - not seen any issues for years now. Would be good to know if this is still 'lurking' in newer versions too?

[Ttelmah]

I'd refer the original poster to the recent thread about a person having problems with a simple delay statement.
It was because he had 'XINST' selected. This is just about the only current 'code' thing likely to cause really unexpected behaviour.
He showed exactly 'how' to get an answer, posting a nice small compilable program that had the problem.
As it currently stands, the question is a bit like a person learning to drive, posting 'my car won't go in a straight line'. Possible answers range from driving on bumpy/canted surfaces, through simply having the wheel turned, to possible actual mechanical faults.
Generally though I have not seen a switch problem, with literally hundreds of programs, except :
1) Very early V4 compilers - trust these as far as you can spit backwards...
2) Very early CCS compilers - probably ten years or more ago now.
3) Specific things like XINST - which an example would have allowed us to see.
4) Some problems with specific simulators, rather than the compiler.

Best Wishes

[DonWare]

OK I'm having the same kind of problem but in another switch statement.

MPLAB version is 8.3.0.0 CCS compiler version is PCH 3.249

In the routine below, I break at the top of the switch and rpc=9. But it steps to case 1.

Sorry the code format looks like crap below but can be pasted and viewed OK. If there's a better way please let me know rather than attack.

Code----------------

int1 performRPC(int8 rpc){
// Depending on rpc number passed, execute code for that rpc.
int1 flag=false;
// int i;

tx_block=FALSE; // Can be set below by 'set' cmd. # 128

switch (rpc){

case 1: // LCD is ready. Not functional on amulet.
// no action
break;
case 2: // Increase procedure select list 4x
inc_sel_list();
break;
case 3: // Decrease procedure select list 4x
dec_sel_list();
break;
case 5: // Stop sequence (stir and heat)
tx_blk_timer=TX_BLOCK_LOAD; // reset timeout timer.
tx_block=TRUE;
break;
case 6: // Save Manual entries: rpm, time, deg C, switch to new procedure mode.
save_man_entries();
break;
case 7: // Increase displayed sequence 1x
show_next_seq();
break;
case 8: // Decrease displayed sequence 1x
show_prev_seq();
break;

case 9: // Save current sequence entries: rpm, time, deg C
flag=save_procedure(); // check entries and save, flag value has no meaning here
break;

case 0x0A: // Save Config screen entries ?????????????
save_config_entries();
break;

case 0x0B: // "New" screen opening
clear_eeprom_dat(); // set all to 0
entry_error=false;
seq_idx[ENTRY_DATA]=1; // seq = 1 of 1

seq_total[ENTRY_DATA]=1;
seq_update(); // send "Seq 1 of 1" to Amulet
proc_saved=false;
seq_saved=false;
break;
//----------------------------------------------------------------------------------------------
case 0x0E: // Select Procedure 1 from list to run
run_procedure(1); // run first procedure in displayed list
break;
case 0x0F: // Select Procedure 2 from list to run
run_procedure(2); // run second procedure in displayed list
break;
case 0x10: // Select Procedure 3 from list to run
run_procedure(3); // run third procedure in displayed list
break;
case 0x11: // Select Procedure 4 from list to run
run_procedure(4); // run fourth procedure in displayed list
break;
//----------------------------------------------------------------------------------------------

case 0x13: // Select Procedure 1 from list to edit
edit_procedure(1); // edit first procedure in displayed list
break;
case 0x14: // Select Procedure 2 from list to edit
edit_procedure(2); // edit second procedure in displayed list
break;
case 0x15: // Select Procedure 3 from list to edit
edit_procedure(3); // edit third procedure in displayed list
break;
case 0x16: // Select Procedure 4 from list to edit
edit_procedure(4); // edit fourth procedure in displayed list
break;
//----------------------------------------------------------------------------------------------
case 0x17: // Delete Current Sequence
delete_current_seq();
break;

case 0x18: // Delete Current Procedure
delete_current_proc();
break;

case 0x21: // Start button in manual.htm
break;

case 0x80: // block xmit during amulet screen change
tx_blk_timer=TX_BLOCK_LOAD; // reset timeout timer.
tx_block=TRUE;
break;

case 0x81: // Un-block xmit after amulet screen change

// may need to add code based on err_source value.

err_source=0; // clear who opened the pop-up screen
tx_block=FALSE;
pop_up_open=false;
break;

case 0x82: // Send serial # and printer headings to amulet
break;

case 0x84: // "OK" button pressed on Pop-Up screen
break;

case 0x86: // send Manual screen elements for display.
break;

case 0x8A: // send procedure names for display on Amulet (to edit)

send_procedure_list(1); // send first 4 active procedure names to amulet
break;

case 0x8B: // send procedure names for display on Amulet (to run)
queue_string(0x28,&proc_list[0][0]);
queue_string(0x29,&proc_list[1][0]);
queue_string(0x2A,&proc_list[2][0]);
queue_string(0x2B,&proc_list[3][0]);
break;

case 0x8C: // 8C: send status screen elements to be displayed.
// and enable automatic updating until
// RPC 80h is set when exiting status screen
break;
default:

return(false); // command not recognized

break;
}

return(true); // OK, command recognized
}[/code]