MPLAB X again.

[Pommie]

Can anyone see what I'm doing wrong here?
I've got a project that's (now) rather large.
I've defined a buffer that's 80 bytes long,

As can be seen from above the buffer shows in variables as correct and the data memory used is 975.
If I now reduce the size of the buffer to 40 (or any other number) it still shows the same in variables,

But the data memory used has reduced to 935 - 40 bytes less. But the variable window still shows it as 80 bytes.
What is more worrying is I can write to the 79th byte of the buffer - yes I wrote 0x55 there.

I've tried everything - deleting buff from variables, renaming it and putting it back - still shows as 80 bytes long.
I'm using the simulator as I currently don't have the hardware.
Sorry about hiding the project name etc but it's obvious who the client is if I don't.
I have a line in the code, sprintf(buff,"TST %3F",2.345); with a breakpoint after it but buffer stays empty.

Thanks,

Mike.

 

[danadak]

Do a quick test of your compiler, declare a buff[40] and write
to buff[80] and see if compiler issues a warning you have over
ranged array bounds. Note I did this in GNU, it compiled but
displayed a warning in IDE. Keep in mind its nothing more
than a pointer, so it will write to whatever address you give it.
Within bounds of overall memory.....

Try a clean and build all if that is an option in compiler.....

Regards, Dana.

 

[Pommie]

I added a buff[70]=0x55; to the version with the buffer declared as 40 (long) and it produced a warning.
A clean and build made no difference.
I'm assuming that a clean will force all files to be compiled.

Mike.

 

[Ian Rogers]

I think crap like this happens when two or more projects are open.. Also if you compile without debug, watch and variable lists are incorrect.. So if one of your open projects is in release mode.. Well MPLABX must have been written by a man.. as it seems to not multitask.

 

[Pommie]

I only have one project open and I am compiling a debug version. The annoying thing is that if I try to make a cut down version to show the problem it's (the problem) not there.
Problems seem to only show up when you have lots of code and are impossible to find.
BTW, I've tried everything. Even the famous "Switch it off and on again".
Hopefully, this will go away on the real hardware.

Thanks all,

Mike.
P.S. if anyone has any suggestion then I'm (still) all ears.

 

[Diver300]

The annoying thing is that if I try to make a cut down version to show the problem it's (the problem) not there.

It might be a worth cutting bits out and narrowing down what does cause the problem. It might be one specific item, or it might be at a certain size of code.

Whatever it is that causes the problem, once you find it, you can tell Microchip.

 

[Pommie]

A little more information,
When I compile it shows buff at address 0x400

However, when I look at the data memory it shows,

These are after the same compile.
This appears to show the buffer at 0x173. I use buff[39]=0x55; to place the end of the buffer.
And sprintf(buff,"TST %f",toFp(539)); to place the text in the buffer.
The function toFp rounds to the nearest mV (it's displaying ADC values as voltages - client prefers voltages) - why is it printing three trailing zeros?
I could try defining a pointer and loading it with the address of buffer but I just won't know if to trust it.

Mike.

 

[granddad]

A long shot... the pack PIC18-K DFP 1.11.281 I had trouble with PIC18F k packs. may be just my set up .

 

[Pommie]

A long shot... the pack PIC18-K DFP 1.11.281 I had trouble with PIC18F k packs. may be just my set up .
View attachment 146103

Brilliant. I've just switched to 1.13.292 and it appears to have fixed it.
At least now it's showing the correct address.
Wait, I've now recompiled and it's gone back to how it was (buff at 0x400).
I really hate MPLABX.

Mike.
P.S. going to try booting into Win10 and see if anything changes.

 

[granddad]

MPLABX is a Fujitsu program {UK post office joke}= "Years of bugs, and people prosecuted and jailed"

 

[Pommie]

Update,
Booted into Windoze (10) and couldn't get it to compile. Kept telling me I hadn't stated the processor - whatever that means.
Rebooted in Linux and it appears to get the address (of buff) correct,

The line that is placing stuff in the buffer is, sprintf(buff,"TST %f",toFp(539));
I'd still love to know where the extra three zeros are coming from.

Mike.

 

[Pommie]

Granddad, really need to watch that documentary. The post office appear to be highly complicit in wrongful convictions.

Mike.

 

[granddad]

UK PO Very disturbing.. A bug ! nah no bugs , your nicked...Paula Would you like a knight hood ...
There is not one program that will not have a bug, and given the scale of the network I think originaly 17,000 terminals, Fujitsu were known for pushing sw to and beyond its limits, From what i have gleaned, if a transaction failed / errored , the system retried , but transmission lags some times retrys caused a duplication ,so money got doubled, Just my take , Horizon was originally Pathway under ICL, was as buggy as h....
Sorry to divert the thread , Back to MPLABX head scratching ..

 

[Pommie]

Have now returned to Linux and have access to Pickit4 and the hardware and (miraculously) all is correct again. Except it's running at 16MHz not 64MHz as I thought.
Whoops, the address of buff is correct (I think) but it still thinks it's 80 bytes long.

And it's full of random characters even after executing sprintf(buff,"TST %f",toFp(539));

Mike.

 

[rjenkinsgb]

Are there any updates for the compiler or linker in use? I'd expect the IDE gets all the symbol data & allocations from the compiler / linker, so problems could well be there rather than in the IDE?

I use MPLab X, but with the CCS compiler & I never get a fraction of the problems I see others mention.

 

[Pommie]

Do you have a 25k22 and can you try running it at 64MHz?

Mike.

 

[granddad]

Mike, Not sure if i have 25K22 will have to check my 'stock' currently 'playing with the PIC18F57Q43 , believe I have used 14F22 at 64mhz,