MPLAB X V6.00 seems to be buggier than ever.

I installed MPLAB X V6.00 trying to get rid of phantom errors - see this thread. I've now got variables that don't exist (according to MPLABX),

in the above it's telling me that checkSum doesn't exist but it's clearly defined at the top of the page. I have a breakpoint on line 51 but in the bottom left it tells me I don't have any breakpoints.
If I click where it says <Enter new watch> then I get this dialog,

I enter the correct name and it just completely ignores it!!!
How is anyone expected to use such a buggy piece of .......

Extremely frustrated,

Mike.
Edit, I need to know what is in checkSum but it won't tell me.
And, yes, it has been successfully compiled and stopped at the (non existent) breakpoint - the green line is where the PC is.
More edit, I had turned off the software breakpoints but they seem to randomly turn on again.
Edit once more, S/W breakpoint are being enabled if I set ANY breakpoint. If I then turn them off the PC just sails right past the breakpoint.

I've now gone back to V2.00 of the XC8 compiler - from V2.32 and I now get a different type of error,

Now it's telling me in the bottom part of the screen that uint24_t doesn't exist but shows it in cyan (meaning no error) in the top part of the screen.
So, I check the XC8 manual to see what Microchip call a 24 bit variable, it's a unsigned short long,


So I change uint24_t to unsigned short long, result,

How can anyone work with this.
I seem to spend more time fighting with MPLABX than writing code.


Mike.
edit, anyone know how I declare a 24 bit variable?
edit2, attempting to switch back to version 5.35 - I think that's what I had previously.

And people kept telling me MPlab X was all good and sorted - oh look, another flying pig.

Re the 24bit variable - info on the Microchip forum suggests you have to change something in the Linker options https://www.microchip.com/forums/m1154266.aspx whether this applies to V5 or 6 - don't know.

I switched back to V5.35 - no change, errors still the same. Switched to xc8 V2.00 - no change. Switched to xc8 V2.10 - all errors gone.
I can even hover over a variable and it tells me it's value,


What I can't figure out is how to stop it using software breakpoints and use the (single) hardware one.

Mike.
Edit, back to using uint24_t without any problems.

Does anyone know how these breakpoints are supposed to work?

My code was stopped at location 0x179 so I set a breakpoint (in the lower window) at this location. The little triangle means it's an address breakpoint.
Note, S/W breakpoints turned off and hardware breakpoints = 0. It does, of course, sail straight past the breakpoint address.
How do I setup a hardware breakpoint?

Mike.

One point is to turn off all compiler optimisation while debugging - the optimiser can rearrange or remove instructions during compilation, so breakpoints end up at the wrong location.

I'm just installing MPLAB X 6 so I'll let you know what happens with my stuff.

When you install XC8 you get the option to try the full version for a month, I declined. The free version has no optimization.

Mike.

You are a few years out of date on the free version capabilities:

Are you looking for code optimizations? Our free MPLAB XC C Compiler comes with the majority of the optimizations you need to reduce your code by up to 70% and increase efficiency. Specifically, the free compiler contains these optimizations:

• O0 - Ensures that your code is in its pristine state
• O1 - Invokes all optimizations that won't affect debugging
• O2 - Invokes a balanced set of speed and size optimizations

When you purchase one of our PRO licenses, you also get the following optimizations:

• Os - Gives maximum code size reductions
• O3 - Gives the best speed optimizations
• mpa (Procedural Abstraction) - Reduces code size even further

Click to expand...

Looks like I am out of date but doesn't "O1 - Invokes all optimizations that won't affect debugging" mean that optimization can't be the problem.

Mike.

Pommie said:

doesn't "O1 - Invokes all optimizations that won't affect debugging" mean that optimization can't be the problem.

Click to expand...

Yep. IF you trust the system to be bug-free there as well!

rjenkinsgb said:

Yep. IF you trust the system to be bug-free there as well!

Click to expand...

This is a result of "the C standard says..."

See my reply to your original thread.