View previous topic :: View next topic |
Author |
Message |
rolox
Joined: 25 Dec 2014 Posts: 33
|
Debug fragmented variables |
Posted: Fri Jan 09, 2015 6:34 am |
|
|
HI,
Not sure if this a MPLAB (8.x or X) or CCS issue :
Often variables are fragmented in the PIC memory. This can be seen in the .sym file. That does usually not really care because the programs work anyway.
But debugging this variables is hard, becuase in the watch window the memory is shown NOT according to symbol table.
In the example, "myVar2" is fragmented by the compiler and locates as follows :
06C-06F,0A0-0A5 main.myVar2
BUT: in Watch window (anyway if MPLAB 8 or X) the memory is shown from 0x6C up to 0x75. So the content is wrong - more or less, depending on the position an probably changing while changing the program...
The question is : can i tell the compiler to NOT fragment certain variables ? There is in fact enough RAM left to fit the varaibles unfragmented....
Code: |
#include <16f1788.h>
#device *=16
#device ICD=TRUE
#DEVICE PASS_STRINGS=IN_RAM
#fuses NOWDT,NOPROTECT,NOLVP, NOPUT
#use delay(internal=16000000)
void main()
{
char dummy1[65]="xxxx";
char myVar1[10]="123456789";
char myVar2[10]="abcdefghi";
//dummy to set a breakpoint
dummy1[0]=1;
} |
|
|
![](templates/subSilver/images/spacer.gif) |
asmboy
Joined: 20 Nov 2007 Posts: 2128 Location: albany ny
|
|
Posted: Fri Jan 09, 2015 7:13 am |
|
|
the data sheet shows the limits of what can be done
look at table 3-3 to see what i am talking about.
since memory is banked on 16F parts - there will never be more than 80 contiguous bytes of SRAM for a VAR.
what is the Harm in what you see?
are program results wrong?
does fragmentation offend your sense of order ??
for a moment forget about MPLAB - that could be a problem right there.
what happens to your compile result with NO ICD in the picture?
IN my world view the best debugger is NOT MPLAB!
It's above your neck and between your ears.
![Very Happy](images/smiles/icon_biggrin.gif) |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19378
|
|
Posted: Fri Jan 09, 2015 8:37 am |
|
|
As Asmboy says, there isn't space to have things un-fragmented on these small page chips. It's an MPLAB limitation, that it can't handle things split across multiple banks. Just create a manual watch at the address of the second part. |
|
![](templates/subSilver/images/spacer.gif) |
rolox
Joined: 25 Dec 2014 Posts: 33
|
|
Posted: Fri Jan 09, 2015 9:06 am |
|
|
Hello guys,
i know that RAM in PIC is fragmented. And i wrote that programs seem to be ok.
What is the harm in wrong debug information ? thats a joking question, isn't it ? if the IDE/debugger shows the value of a variable wrong - its worthless.
I dont' care where the compiler puts its variables - als long as i can have an eye on it.
In fact, there is enough RAM for this variables to have them unfragmented. Have a look at the code. none of the three vars i >80byte - so why fragment the one which is just 10bytes long.
The point is : has anyone else the need to have a look at the programs vars during development ? everything works right from the start ?.... |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9177 Location: Greensville,Ontario
|
|
Posted: Fri Jan 09, 2015 9:56 am |
|
|
one potential reason for the fragmentation is that you've said ICD=TRUE.
this means the compiler/PIC/MPLAB have to use PIC resources diferently than had you not used the ICD.
Don't ask me specifics as I never use the ICD, prefer to use 'release' mode and do real world testing. Others who use ICD can reply what happens.
I'm 'old school', never found a 'simulator' that worked right either and since the program has to work i the real world, that's where I test.
Jay |
|
![](templates/subSilver/images/spacer.gif) |
rolox
Joined: 25 Dec 2014 Posts: 33
|
|
Posted: Fri Jan 09, 2015 10:23 am |
|
|
omitting "#device ICD=TRUE"
does not change the behaviour.
Anyway - i know the ICD uses some resources, depending on the PIC device. According to Microchip there were no resources used in the 16F1788.
But even if that were the case - there is enough RAM left.
ICD3 is working quite well for my needs - but i wonder why the watch window does not take care of the symbol table (or not correctly).
This may not be a CCS issue, but i was hoping for some hint on a hidden pragma like '#keep_vars_together' or whatever
I'll check Microchipforum for this issue too....no result yet |
|
![](templates/subSilver/images/spacer.gif) |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Fri Jan 09, 2015 12:37 pm |
|
|
In older compiler versions, arrays could not be larger than a ram page,
nor could they span a page. But now they can.
How to get around this ?
You can force the myVar2 array to start at the beginning of a page
with #locate. Add the line shown in bold below:
Quote: | char dummy1[65]="xxxx";
char myVar1[10]="123456789";
char myVar2[10]="abcdefghi";
#locate myVar2 = 0xA0
|
This table from the 16F1788 data sheet shows the starting addresses
of the RAM banks:
Quote: | TABLE 3-3: PIC16(L)1788 MEMORY MAP (BANKS 0-7) |
The .sym file shows that myVar2 is now contiguous:
Code: |
021-061 main.dummy1
062-06B main.myVar1
077 @SCRATCH
078 @SCRATCH
078 _RETURN_
079 @SCRATCH
07A @SCRATCH
0A0-0A9 main.myVar2
|
Tested with vs. 5.036. |
|
![](templates/subSilver/images/spacer.gif) |
rolox
Joined: 25 Dec 2014 Posts: 33
|
|
Posted: Sat Jan 10, 2015 4:58 am |
|
|
hello pcmprogrammer,
ok, then just "myVar2" is unfragmented - but then the next one may be ....
this solution may help for small programs - but i cannot keep track of all my vars after each compile just to see if the compiler does a fragmentation and then add a manual #locate to avoid that - a global compiler flag would be the solution - probably already existing .... but unknown |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19378
|
|
Posted: Sat Jan 10, 2015 5:07 am |
|
|
No form of global flag could work, without wasting most of the memory.
Think about the implications if things can't cross boundaries.
What is needed is MPLAB to start supporting multiple page variables. |
|
![](templates/subSilver/images/spacer.gif) |
rolox
Joined: 25 Dec 2014 Posts: 33
|
|
Posted: Sat Jan 10, 2015 5:27 am |
|
|
The wasted memory surely depends on the sort and amount of vars used/needed for a program. I posted a thread on Microchip forum about this issue...all i got till know was kinda "...forget the debugger, use your brain..." ..but all i'm asking for is a that offered features (watching a var through debugging...) are working as expected :-( ...or at least a workaround ..... |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9177 Location: Greensville,Ontario
|
|
Posted: Sat Jan 10, 2015 6:27 am |
|
|
You could email Microchip's MPLAB software group and ask if they'll fix that 'bug'. I did that years ago when I got 'hit' with the 'debug' mode as the default config. Having to manually change that EVERY time was tedious( I always use 'release'). One of the IT guys called me, was intrigued how I was using MPLAB(seemed 'normal' to me), sent me a 'patch' to run, then a few months later MPLAB had the patch in it!
Never hurts to ask !
Jay |
|
![](templates/subSilver/images/spacer.gif) |
asmboy
Joined: 20 Nov 2007 Posts: 2128 Location: albany ny
|
|
Posted: Sat Jan 10, 2015 9:43 am |
|
|
going back to the original question
Quote: |
can i tell the compiler to NOT fragment certain variables ? |
PCM_Programmer posted the best solution for what you asked.
In these small , banked memory model chips , setting the page by
#locate, per var array, is the only reasonable answer to your question.
IF you have a communication channel ala #USE RS232
then write some CCS printf() code to
transmit the var value in question to a pc or other monitor.
An FTDI RS232 to USB chip is very helpful in that regard.
and forget about fixed breakpoints while you are at it too.
when it comes to debugging - adding some additional conditional code
has always been my approach to debug of "values" in a running program.
AT least i have control of what actually gets compiled.
my 2 cents : MPLAB is just more trouble then it is worth.
If you were to poll long time professional CCS PIC programmers, i suspect you won't find a huge number of MPLAB "believers" in that crowd.
I'm willing to be corrected on this point however.
Anybody? ![Very Happy](images/smiles/icon_biggrin.gif) |
|
![](templates/subSilver/images/spacer.gif) |
rolox
Joined: 25 Dec 2014 Posts: 33
|
|
Posted: Sat Jan 10, 2015 10:43 am |
|
|
@asmboy : you right, sending the "needed" vars values via rs232 is just an option - the actual hardware has in fact the ftdi already attached ...coming from nec/renesas it was always the easy way just to have the look at all the vars if desired ...but you may absolutely be right that MPLAB is not the best solution, and i tried the 8.x and X - using ICD3 AND having several watches open slows down system.
Using PCMprogrammers hint at least while debugging a special part of the program and certain vars in fact seems to be the best way for me at the moment (i confess i did not have a look at the CCS IDE at all).
edit : did an import from MPLAB to CCS IDE - was less work than expected....having a look at the watch on the fragmented vars - same result as with MPLAB, watch window shows wrong values. Maybe thats an ICD problem rather than an IDE problem....at least i found the CCS IDE more comfortable than MPLAB 8. |
|
![](templates/subSilver/images/spacer.gif) |
|