MCS 3.0.0.5 'bytes used' report sometimes inaccurate.

[skimask]

I've noticed that the 'bytes used' line at the bottom of the screen is always an odd number, and just today, after compiling my latest, greatest, colonized program, the 'bytes used' number turned out to be exactly 1,000 bytes high (should've read 64,869, actually read 65,869). Checked with the .lst and .hex file, and with the window in the PICKit2 software. The 64,869 is the correct number.
Anybody had this issue yet? Or is it just me

[Darrel Taylor]

Can't say if it's just you or not, but ...

I get the exact opposite.

Whatever I do, everything compiles to an Even number of bytes.
The number is reported by MPASM. MCS just passes it along.

Thought maybe there could be a problem when things go over 65535, so I made a quick test program that just uses however many NOP's you want to suck up program space.

It always reports the correct number of bytes, +4-6 that PBP adds.

ASM
UseSpace  macro Words
     variable HighLoop = high(Words)
     while HighLoop > 0
         variable LowLoop = 255
         while LowLoop > 0
             nop
             variable LowLoop = LowLoop - 1
         endw
         nop
         variable HighLoop = HighLoop - 1
     endw
     variable LowLoop = low(Words)
     while LowLoop > 0
         nop
         variable LowLoop = LowLoop - 1
     endw
  endm
ENDASM

@  UseSpace  33000

Maybe you can try it to see if the results are different.

Are you using an @ db xx anywhere?
<br>

[skimask]

Not using any 'db' or 'dw' anywhere or anything out of the ordinary.
I do have a couple of macro's (the color LCD macros) going with numerous instances of those. However, I added a few lines just to get the total bytes used up to 65,535 exactly...came up correct, and again, still odd. Tried to force an even number using a few NOPs, couldn't do it. And this is again, only using an 18F4620.

Maybe it's a bug in the older version of MPLAB. I'm still running the 'stock' 7.62 of MPLAB, MPASM 5.13. (don't have a need for the newer version yet, if it ain't broke....)

I'll have a play with the above code later on...


EDIT: Updated to MPLAB 8.02 along with the latest PICKIT2 software/firmware (thanks Mr_E for the heads up). Same results, except that I haven't seen the count be 1,000 off. Now it's always odd and sometimes 1, 10, or 100 off. Haven't played with the code yet...

[skimask]

Yes, the bytes are -slightly- inaccurate just like you said. PBP and/or MCS adds a few bytes to the total...or does it?
I'm fairly sure MCS takes into account ALL bytes programmed...config bytes, eeprom, program space, everything.
In my situation, if I add together what the PICKIT software shows as the top of the program, add in all of the eeprom DATA statements, add in the eeprom used by my font, add in the 6 or so CONFIG fuse words, etc, it all adds up to the amount shown at the bottom of the screen by MCS.
Delete all of the DATA and EEPROM statements, and the total comes out to be about 4-6 bytes off. Remove anything resembling a CONFIG fuse from the .inc file, and the numbers are identical.

[Darrel Taylor]

Figured it out? Doesn't sound like it.

Ok, so the unexpected used space is from the EEPROM or CONFIGs.
That's interesting. Never realized that was included in the the Byte total.
Now I can stop freaking out, thinking I'm only 100 bytes from the end, when there's 1K of EEPROM data too. Cause there's still 1K+ of program space left. Good news!

But it doesn't explain the ODD number of bytes. I've tried Configs, EEPROM, DATA, DB, DW, DA and no matter what, I can't make it come up ODD.

When you use the code above, does it give even or odd numbers. (in a program by itself)
<br>

[skimask]

But it doesn't explain the ODD number of bytes. I've tried Configs, EEPROM, DATA, DB, DW, DA and no matter what, I can't make it come up ODD.

When you use the code above, does it give even or odd numbers. (in a program by itself)
<br>

Ok, now that is weird...I can't get it to come up EVEN!
If I use the above code, using 33000, obviously I get maximum address errors, but it still gives me 66015 bytes used. If I use 32000, I get 64015.
Not that it'll matter much, but this is the include file I use. I haven't modified any other files, PBP or MPLAB types...

;****************************************************************
;*  18F4620.INC                                                 *
;*                                                              *
;*  By        : Leonard Zerman, Jeff Schmoyer                   *
;*  Notice    : Copyright (c) 2006 microEngineering Labs, Inc.  *
;*              All Rights Reserved                             *
;*  Date      : 06/05/06                                        *
;*  Version   : 2.47                                            *
;*  Notes     :                                                 *
;****************************************************************
        NOLIST
    ifdef PM_USED
        LIST
        "Error: PM does not support this device.  Use MPASM."
        NOLIST
    else
;original listing below
;       LIST
;       LIST p = 18F4620, r = dec, w = -311, w = -230, f = inhx32
;        INCLUDE "P18F4620.INC"	; MPASM  Header
;        __CONFIG    _CONFIG1H, _OSC_XT_1H
;        __CONFIG    _CONFIG2H, _WDT_ON_2H & _WDTPS_512_2H
;        __CONFIG    _CONFIG3H, _PBADEN_OFF_3H
;        __CONFIG    _CONFIG4L, _LVP_OFF_4L & _XINST_OFF_4L
;        NOLIST

	LIST
	LIST p = 18F4620, r = dec, w = -311, w = -230, f = inhx32
	INCLUDE "P18F4620.INC"	; MPASM  Header
	CONFIG OSC = HSPLL, FCMEN = ON, IESO = ON, PWRT = ON
	CONFIG BOREN = OFF, BORV = 0, WDT = OFF, WDTPS = 32768
	CONFIG MCLRE = ON, LPT1OSC = OFF, PBADEN = OFF
	CONFIG CCP2MX = portc, STVREN = OFF, LVP = OFF 
	CONFIG XINST = OFF, DEBUG = OFF, CP0 = OFF, CP1 = OFF
	CONFIG CP2 = OFF, CP3 = OFF, CPB = OFF, CPD = OFF
	CONFIG WRT0 = OFF, WRT1 = OFF, WRT2 = OFF, WRT3 = OFF
	CONFIG WRTB = OFF, WRTC = OFF, WRTD = OFF, EBTR0 = OFF
	CONFIG EBTR1 = OFF, EBTR2 = OFF, EBTR3 = OFF, EBTRB = OFF
	NOLIST
    endif
        LIST
EEPROM_START	EQU	0F00000h
BLOCK_SIZE	EQU	64

Which PIC are you using for your testing?

EDIT/UPDATE: I just tried an 18F4680 for grins...used 32000 for the code, got 64012 bytes used, 3 less than when using the '4620. Different formats in the PBP .INC file methinks...