| View previous topic :: View next topic |
| Author |
Message |
JerryR
Joined: 07 Feb 2008
Posts: 167
|
| Debugger stepping over code |
 Posted: Sat Jan 06, 2018 9:14 am |
 |
|
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: 9244
Location: Greensville,Ontario
|
|
| Posted: Sat Jan 06, 2018 9:24 am |
|
|
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: 167
|
|
| Posted: Sat Jan 06, 2018 9:31 am |
|
|
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: 19543
|
|
| Posted: Sat Jan 06, 2018 9:49 am |
|
|
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: 21708
|
|
| Posted: Sat Jan 06, 2018 9:49 am |
|
|
| 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: 167
|
|
| Posted: Sat Jan 06, 2018 9:54 am |
|
|
Hi PCM
I currently have a PICKit3 attached, but have also tried a RealICE.
Thanks! |
|
|
JerryR
Joined: 07 Feb 2008
Posts: 167
|
|
| Posted: Sat Jan 06, 2018 10:20 am |
|
|
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: 167
|
|
| Posted: Sat Jan 06, 2018 10:51 am |
|
|
New hint:
Code only executes from the MAIN routine. Calls outside MAIN routine are ignored! |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9244
Location: Greensville,Ontario
|
|
| Posted: Sat Jan 06, 2018 2:30 pm |
|
|
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: 19543
|
|
| Posted: Sat Jan 06, 2018 3:04 pm |
|
|
| 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: 167
|
|
| Posted: Sat Jan 06, 2018 4:33 pm |
|
|
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: 167
|
|
| Posted: Sat Jan 06, 2018 4:44 pm |
|
|
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: 19543
|
|
| Posted: Sun Jan 07, 2018 2:01 am |
|
|
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: 19543
|
|
| Posted: Mon Jan 08, 2018 2:24 am |
|
|
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. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
