I am using the MCP79511 rtc time set or read using the same read/write functions are working correct. however; writing the EEprom seems to fail.
Reading ID is working when activated and eeread dis-activated.
I did try to follow the manual. (page 10/ 37/40)
http://ww1.microchip.com/downloads/...CP7952X-Battery-Backed-SPI-RTCC-20002300C.pdf
What do I wrong or it's just a reading problem?

Picbuster

// delays added to make measurement easier.

// test mcp79511   eeprom
//================ read ======================
  RTC_Ena=Low;
  __delay_ms(1);
  WriteSPI2(0b00000011);  // EEread
  //  WriteSPI2( 0b00110011);  // read ID 7  working
  WriteSPI2(0);
  for (int i=0 ;i < 7;i++)
  {
  int a = ReadSPI2();
  printf("%d ",a);
  }
  printf("\r\n");
  RTC_Ena=High;
   // ========================= end read =========================
 
  __delay_ms(30);

  //  ===============  write ========================
// ------------ set EEwren conform manual --------------------------------- 
  RTC_Ena=Low; 
  __delay_ms(1); 
  WriteSPI2(0x00000110);  // EEwren 
  RTC_Ena=High;
 
//--------------------------------------------------------------------------- 
  __delay_ms(1);

  RTC_Ena=Low;
 
  WriteSPI2(0b00000010);                    // EEwrite mode 
//------------------------------------------------------------------------------
  WriteSPI2(0x0);                                   // start address 
  WriteSPI2(0b00100000);                   // just 4 bytes of data
  WriteSPI2(0b00100001);
  WriteSPI2(0b00100010);
  WriteSPI2(0b00100011);
//------------------------------------------------------------------------------ 
     __delay_ms(1);
  RTC_Ena=High;
 
//================= end write =======================

Moderators note : used code tags for C

 

Don't feel discouraged. The solution is in the datasheet. At least usually. Go through the procedure outlined in the datasheet carefully and check every aspect of every operation and you are sure to find it. I have not had any experience with that particular chip but have made some of their EEPROMs work, though it took an agonizingly long time to obtain success. The problem might be something as mundane as correct power supply decoupleing reflections on a data or write line or even the ground.

 

The code fragment doesn't show the read/write routines themselves so take this FWIW:

If your SPI routines use the SSP hardware, they need to read SSPBUF after each write to retrieve the data on MISO. If you dont, you'll get a WCOL and the SSP may cease to work until that is cleared. (working from memory here).

Line 12 is goofy - declaring and initing by calling a function is a new one for me. Doesn't mean it won't work but when things aren't working it's usually best to do things simple - declare the variable separately. It's likely that once the variable is initialized, line 12 won't be executed again so no further reads. It's also possible that the compiler is doing the init during the startup phase and not where it's shown. You can step the code or inspect the generated assembler for sure but the easy way is just to separate the declaration from the value assignment. I avoid inline declarations like this - it's much easier to know what your variables are when they are declared at the top of a routine or file (depending on scope).

If ReadSPI2() returns a character explicitly cast it to an int. If the compiler is generating warnings, fix those before proceeding.

I assume you have provided a suitable putc routine for printf. Personally, I'd try not to use printf as a diagnostic here. If you are using a programmer/debugger, just set a breakpoint after the read and use the Variables or Watch window to inspect the returned value. printf just adds a lot of overhead that you don't want when you are getting things up for the first time.

Good luck!

 

Thanks for the answers however;
I did follow the manual step by step. The same Read and write functions are used as supplied by microchip.
The process is working for reading and setting the time. This should work with this EEprom mechanism as well.

According to line 12 I do normally use this but changed as mentioned. no effect
Breakpoints: The EE data goes out correctly butt comes back as FF (serial number read does work correct)
Then a read status (SRREAD) is send a received result is 2 (indicating write enabled no process going on.)

Now I can send EEWRITE command, address databyte) ( all with the correct set of enable / disable)
It is transmitted .

Chip partially dead?

Picbuster