# Am I missing something or is MPLABX completely unusable?

#### Pommie

##### Well-Known Member
I have just wasted 2 hours trying to figure out why I couldn't write to EEPROM in a 18F26K22. I ended up with just code to write the EEPROM,
Code:
    EEADR=0x30;
EEDATA=0xAA;
EECON1bits.EEPGD=0;
EECON1bits.CFGS=0;
EECON1bits.WREN=1;
EECON2=0x55;
EECON2=0xAA;
EECON1bits.WR=1;
EECON1bits.WREN=0;
I then checked the EEPROM memory window and nothing had changed. I read everything I could find. Tried various things, nothing.

It got to the point where I'm thinking maybe a bug in the chip. To test my sanity, I added a read back from EEPROM and the data was there!!!

Turns out the EEPROM memory window in MPLABX does not show the contents of the EEPROM!!!! What use is that.

I eventually worked out that you can see the EEPROM by doing the following,
Stop the debugger.
Press the Read Memory icon on the ribbon.
Open the EEPROM memory window.

Thanks for nothing Microchip.

Mike.

##### Well-Known Member
I am still using MPLAB IDE 8.92, working with Assembly I just couldn't get any success with MPLABX.
Max.

##### Active Member
Hope I am not teaching my granny to suck eggs This was my final working EE code for a PIC18F14K22 the MPLABX 5.15 view of ee data memory is ' flexible' not always the current data , guess you found that out. Mike I had to select different memory view then go back to eedata memory.. Dont forget to set the programmers 'preserve EEdata bit and address ..
C:
unsigned char readEEPROM(unsigned char ee_addr)
{
EECON1bits.EEPGD = 0;//Point to Data Memory
EECON1bits.CFGS=0; // Access EEPROM
EECON1bits.RD = 1; //Initialise read cycle
return EEDATA; //Returning data
}
void writeEEPROM(unsigned char ee_addr, unsigned char nv_data)
{
unsigned char INTCON_SAVE;//To save INTCON register value
EEDATA = nv_data; //Data to write
EECON1bits.EEPGD = 0; //Selecting EEPROM Data Memory
EECON1bits.WREN = 1; //Enable writing of EEPROM
INTCON_SAVE=INTCON;//Backup INCON interupt register
INTCON=0; //Disables the interrupts
EECON2=0x55; //Required sequence for write to internal EEPROM
EECON2=0xAA; //Required sequence for write to internal EEPROM
EECON1bits.WR = 1; //Initialise write cycle
INTCON = INTCON_SAVE;//Enables Interrupt from saved
EECON1bits.WREN = 0; //To disable write
while(PIR2bits.EEIF == 0)//Checking for complition of write operation
{
Nop(); //do nothing
}
PIR2bits.EEIF = 0; //Clearing EEIF bit
}
With apologies to all C programmers ..
MPLABX is a much nicer friendly experience with linux.mint 19.x I keep one PC just for it

#### Pommie

##### Well-Known Member
Thanks guys. The routines I originally wrote worked fine, it was just the fact that MPLABX pretended to show me the contents of the EEPROM that had me trying to find out why it didn't work. It's a bit like having a watch window that doesn't show you the value of your variables unless you stand on one leg and throw salt over your left shoulder.

Mike.

#### Pommie

##### Well-Known Member
OK, a new problem. I'm writing an I2C slave and have the following problem.
I have this bit of code,

I set a break point on the line SSP1BUF=temp;
The code stops, I single step it to copy temp into SSP1BUF and the two locations contain different values!!

The variable temp contains 'H', SSP1BUF contains,

7F???

And the thing is, I don't know IF it contains 0x7F or if MPLABX is lying to me??

I considered that another transfer was taking place and overwriting SSP1BUF so, I disconnected the other end before single stepping. Still the same.

I even put a test to see if SSP1BUF equaled temp and it didn't.
Note that the master can't start clocking out the value until the line SSP1CONbits.CKP=1 has been executed - the clock is being stretched.

Anyone got any suggestions at all?

Mike.

##### Active Member
Hi Mike . Break points are notorious for 'slipping' what ver MPLABX you running .. also a good idea to turn all other programs internet, put in a Nop(); and break on that...could try to set up a watch Not done a lot with SPI , so just my two cents ( penneth )

Last edited:

#### Pommie

##### Well-Known Member
Hi Granddad, I know about the break point slip but this is something else but I may have found the problem. If the R/W of the address is set then no clock stretching takes place and an automatic ACK is generated. I finally got it figured out but my mistrust of MPLABX is going to take a long time to fade.

Mike.

##### Active Member
Well yes you have to second guess MPLABX all the time ... it has gradually got better (ish) i watch the versions and wait before upgrading . I run 64 bit linux.mint 19.2 and MPLAB 5.15 PK3 , and 'play' with PIC 24, ds33, 18 and 12 , but you have to work hard with data sheets, but when i compare to arduino stuff ..it seems a walk in the park..

#### rjenkinsgb

##### Well-Known Member
I suspect writing to SSP1BUF triggers a transmission even when the program has a breakpoint.

I'm not familiar with that exact device (if it's the same as at the start of the thread), but some of the built-in peripherals also contain FIFO buffers for transmit and receive, or latches to avoid reading changing data.

You are better off looking at the end result or external pin data to verify the program routine, a lot of the time.

#### gophert

##### Well-Known Member
Agree with rjenkinsgb . A little i2c 1602 LCD display makes life so easy. Write the variable you're sending to EeProm to one row of the display, write it to EeProm, read it, write the value retrieved from EEProm to second line of display.

#### BobW

##### Active Member
Recently, I spent a rather unproductive day trying to debug a similar problem in a 16F1703. I thought there was a bug in my code that was corrupting the Flash data memory. It turned out that MPLAB-X was writing garbage to the last 16 words of memory, which is the high endurance flash section where I was storing user configurable data. Reading through the release notes of the latest and previous versions, MPLAB-X has a lot of problems where it doesn't write correctly to flash data memory. Issues known by Microchip for quite a while, but no fixes.