Am I missing something or is MPLABX completely unusable?

[Pommie]

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,

    EEADR=0x30;
    EEADRH=0;
    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.

 

[MaxHeadRoom78]

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

 

[granddad]

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 ..

unsigned char readEEPROM(unsigned char ee_addr)
{
  EEADR = ee_addr; //Address to be read
  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
  EEADR = ee_addr; //Address to write
  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]

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]

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.

 

[granddad]

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 )

 

[Pommie]

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.

 

[granddad]

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]

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]

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]

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.