CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug Reports on this forum. Send them to support@ccsinfo.com

Debugger stepping over code

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
JerryR



Joined: 07 Feb 2008
Posts: 133

View user's profile Send private message

Debugger stepping over code
PostPosted: Sat Jan 06, 2018 9:14 am     Reply with quote

Hello group: I have an issue that's been occurring intermittently with various projects and would like some input from the group on.
I have code that executes correctly and predictably on one PC and has issues on other PC that I move the project to.

I am using CCS Compiler 5.071 and debugging a PIC16F1517. I'm using MPLAB 8.90 as my IDE.

When I open the project on the problem PC debugging steps over any call to an included file. Watching the code execute on the disassembly listing GOTOs are just ignored when the GOTO is associated with an included file.

Again, I can take the same project over to another PC and it executes correctly and predictably. This issue has bugged me for some time. I have uninstalled and re-installed MPLAB and the CCS Compiler and the issue still occurs.

I appreciate the groups input on this issue. THANKS!
temtronic



Joined: 01 Jul 2010
Posts: 6290
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Sat Jan 06, 2018 9:24 am     Reply with quote

DEDICATE a PC, super cheap these days, for JUST PIC programming and testing. ONLY have basic Windows, CCS and MPLAB. Use a flash drive to copy stuff like datasheet PDFs to it. Do not have internet access UNLESS you disable ALL 'autoupdate' options to programs. NO emails,word, spreasheets, etc. This is a 'PICputer' !
I've seen the horror of 'some program' altering USB registers (why is anyone's guess) and spending hours wondering what 'I' did..when it wasn't me !

Jay
JerryR



Joined: 07 Feb 2008
Posts: 133

View user's profile Send private message

PostPosted: Sat Jan 06, 2018 9:31 am     Reply with quote

Hi Jay:

Thanks for your input. I generally do have a dedicated PC per project. I multitask a lot and routinely move projects from PC to PC however to accommodate test equipment requirements.

There must be a way of returning the affected workstation to operation, however.

Thanks again!
Ttelmah



Joined: 11 Mar 2010
Posts: 13674

View user's profile Send private message

PostPosted: Sat Jan 06, 2018 9:49 am     Reply with quote

In your source code, open the processor include file.
Couple of lines down from the top, there is a line #NOLIST.
Remark this out //
When you save, it'll say this is a CCS file. Tell it to save a copy with the project.
Recompile.
Now listings will be included for all the CCS functions.
Select the assembler file and you can step through the actual assembler line by line, and even stop mid function.

I must admit I always run a global search and replace on the devices directory for each compiler, changing this line. For debugging, not having assembler for the supplied functions is a real annoyance.
The .cof file generated does not include the debugger information allowing breaks etc., for the internal functions, till this is done.


Last edited by Ttelmah on Sat Jan 06, 2018 9:52 am; edited 1 time in total
PCM programmer



Joined: 06 Sep 2003
Posts: 20404

View user's profile Send private message

PostPosted: Sat Jan 06, 2018 9:49 am     Reply with quote

Quote:
I am using CCS Compiler 5.071 and debugging a PIC16F1517. I'm using MPLAB 8.90 as my IDE.

What debugger do you have selected in MPLAB when you are doing this ?
JerryR



Joined: 07 Feb 2008
Posts: 133

View user's profile Send private message

PostPosted: Sat Jan 06, 2018 9:54 am     Reply with quote

Hi PCM

I currently have a PICKit3 attached, but have also tried a RealICE.

Thanks!
JerryR



Joined: 07 Feb 2008
Posts: 133

View user's profile Send private message

PostPosted: Sat Jan 06, 2018 10:20 am     Reply with quote

Ttelmah, et al:

Thanks for your input as well. I can see the assembly code fine. GOTOs are ignored when the call is to a procedure in an included file, The included file's code is visible in the assembly listing, but the goto (to the procedure in the included file) from within the MAIN routine is ignored.
On a PC, where the code runs predictably, the goto successfully call the procedure in the included file.

Does this make since?

Regards,
JerryR



Joined: 07 Feb 2008
Posts: 133

View user's profile Send private message

PostPosted: Sat Jan 06, 2018 10:51 am     Reply with quote

New hint:

Code only executes from the MAIN routine. Calls outside MAIN routine are ignored!
temtronic



Joined: 01 Jul 2010
Posts: 6290
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Sat Jan 06, 2018 2:30 pm     Reply with quote

OK, please humour me, after all it's -20*C here today...
a couple of tests as I'm trying to decide where the fault lies...

If you create a program X on PC A,compile, it runs the proceedures in the include
BUT
if you create that program X onto PC B, compile, it does NOT run the proceedures in the include ?

the other variation is...
if you compile X on PC A, it works... does it also work if copied onto PC B ?

the first would indicate a compiler issue, the 2nd an execution issue.

any chance A is done in release mode, and B in debug mode ?

just trying to eliminate 'something'. Can you post a small program that does fail? Have to admit that the same program running on A and not B is baffling, that's why I'd do both test above.

Jay
Ttelmah



Joined: 11 Mar 2010
Posts: 13674

View user's profile Send private message

PostPosted: Sat Jan 06, 2018 3:04 pm     Reply with quote

JerryR wrote:
New hint:

Code only executes from the MAIN routine. Calls outside MAIN routine are ignored!


Exactly.

If you compile with the #nolist in the device file removed or remmed out, the compiler adds the entries to the COF file to allow you to step into it's own internal routines. Without this done, though you can 'see' the assember from MPLAB (it disassembles the file itself), there are no entries to allow debugging into these routines.
Is it possible that the device file on one machine has been modified this way, and the other has not?.
JerryR



Joined: 07 Feb 2008
Posts: 133

View user's profile Send private message

PostPosted: Sat Jan 06, 2018 4:33 pm     Reply with quote

Jay:

About as tired of the winter here as well 5 degrees here though

Programs written and debugged successfully on PC A do not "debug" or run on PC B using the same compiler version and MPLAB 8.90 IDE. The symptom is that the debugger on PC B appears to step over any call to any routine. See code below as an example.

Code:

//==============================================================================
[b]void Ck_Keypad(void)[/b]
{


if (input (Right_Key) == 0)
   {
   Screen_Num++;
   Show_Screen(Screen_Num);         //increment and show next screen
   delay_ms(1000);                  //delay after showing screen
   if (Screen_Num >=6)
      Screen_Num= 0;
   }

if (input (Left_Key) == 0)
   delay_us(1);

if (input (Center_Key) == 0)
   {
   Screen_Num= 0;                  //return to home screen
   Show_Screen(Screen_Num);
   }
}
//==============================================================================




//==============================================================================
void main()
{
int8 i,t;
int8 b1, b2, b3, b4;
int8 data;

//Timer0 (RTCC) zero for one second timer
setup_timer_0(RTCC_INTERNAL|RTCC_DIV_256|RTCC_8_BIT);
enable_interrupts(INT_TIMER0);
set_timer0(61);


set_timer1(0);           
setup_timer_1(T1_INTERNAL | T1_DIV_BY_8); 
setup_ccp1(CCP_CAPTURE_RE);   


clear_interrupt(INT_CCP1);
enable_interrupts(INT_CCP1);


lcd_init();

// Clear the LCD.
printf(lcd_putc, "\f");
delay_ms(500);

enable_interrupts(GLOBAL);      //enable all interrupts
enable_interrupts(INT_TIMER0);
enable_interrupts(INT_RDA);



Screen_Num= 0;               //start at screen number 0
Show_Screen(Screen_Num);      //show screen

Run_Time= read_float_eeprom(0);   //pick-up engine run time

while(1)
     {
   Blue_Send();
   Calc_Eng_RPM();
   [b]Ck_Keypad();[/b]
   delay_ms(250);
   if (Update_Screen== TRUE)         //time to update screen (every second)
      {                        //then...
      Update_Screen= FALSE;         //reset flag

//enable_interrupts(INT_TIMER1);
//enable_interrupts(INT_TIMER2);      Show_Screen(Screen_Num);      //show screen
      }
   Ck_Engine_Time();





     }   

}



Again, this is a snippet of code from this project. PC A runs code fine, PC B the code does not run and, when debugging, the cursor does not execute "Ck_Keypad(); (for instance) it just drops to the next line below it (delay_ms(250); Bottom line no call is executed.

This has happened to me before with another project. Workaround was to move all test equiptment near the working PC and proceed.

Ttelmah: I think I understand. Comment-out the NOLIST on the working machine and try on the non-working machine. I'll give that a try, thanks.
JerryR



Joined: 07 Feb 2008
Posts: 133

View user's profile Send private message

PostPosted: Sat Jan 06, 2018 4:44 pm     Reply with quote

Ttelmah:

Same thing! Just steps over any call to a procedure.

Another hint: Got to be something with the MPLAB IDE and CCS Compiler issue. Debuggin works on previuosly non-functioning PC if I use the CCS V5 IDE with one of their debuggers (ICD_U64).

Pretty confused and frustrated when you can't make tools work. Really slow you down!

Thanks anyway!
Ttelmah



Joined: 11 Mar 2010
Posts: 13674

View user's profile Send private message

PostPosted: Sun Jan 07, 2018 2:01 am     Reply with quote

OK. It sounds almost as if on one machine the 'step into' key is being seen as the 'step over' key.
Does it do the same if you use the pull down from the top toolbar or the buttons on the debug tools, rather than a key?. If you are using one of these, does it do the same with one of the other ways of operating?.
Does it do the same if you step through a small section using the simulator, rather than the hardware debugger?.
Are you copying over just the .hex or the .cof as well?.
Ttelmah



Joined: 11 Mar 2010
Posts: 13674

View user's profile Send private message

PostPosted: Mon Jan 08, 2018 2:24 am     Reply with quote

Thinking about it, I think I know what is wrong.

When you program a chip to debug, as well as the code itself, a small 'debug executive' is written to the chip. This comes from the local machine. What you are describing will sometimes happen if this executive is wrong. It sounds as if one machine has a different copy of the executive from the other. These are held in subdirectories from the MPLAB directory, for your particular ICD. It sounds as if one copy of MPLAB has a different version of the code for your PicKit and this processor....
The executive also needs to match what the ICD being used expects, so if the versions differ, then problems, even if the chip is programmed on the 'working' machine.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group