It is currently 23 Jul 2019 03:42

All times are UTC + 1 hour




Post new topic Reply to topic  [ 13 posts ] 
Author Message
PostPosted: 22 Apr 2008 13:50 
Offline

Joined: 22 Apr 2008 13:48
Posts: 6
Here's my simple program on trying to write on EEPROM addresses 0x00 to 0x02, all containing 0x00. The problem is once I write 10 while x = 0, reader will have a value of 10 on EEprom_Read(1) and so on.. Why does EEprom_Read return the value of the data written at 0x00?

unsigned short x = 0, reader = 0;
void main() {
for (x = 0; x < 3u; x++) {
reader = EEprom_Read(x);
if (reader == 0) {
EEprom_Write(x, 10);
}
}
}


Top
 Profile  
 
 Post subject:
PostPosted: 22 Apr 2008 14:15 
Offline

Joined: 18 Feb 2006 13:17
Posts: 5124
You've forgotten to wait for EEPROM_WRITE to finish writing. Check the help file.


Top
 Profile  
 
PostPosted: 22 Apr 2008 22:32 
Offline

Joined: 17 Nov 2007 23:05
Posts: 179
Location: Melbourne Australia
Winterburn wrote:
Here's my simple program on trying to write on EEPROM addresses 0x00 to 0x02, all containing 0x00. The problem is once I write 10 while x = 0, reader will have a value of 10 on EEprom_Read(1) and so on.. Why does EEprom_Read return the value of the data written at 0x00?

unsigned short x = 0, reader = 0;
void main() {
for (x = 0; x < 3u; x++) {
reader = EEprom_Read(x);
if (reader == 0) {
EEprom_Write(x, 10);
}
}
}


Also default data in the eeprom is 0xff not 0x00

Puggs

_________________
PIC Web http://nbit.biz:8181/
http://www.accesspointlive.com/
http://www.trillianstatus.com/
http://www.nbit.biz/
http://www.TBBS.org/


Top
 Profile  
 
 Post subject:
PostPosted: 23 Apr 2008 12:28 
Offline

Joined: 22 Apr 2008 13:48
Posts: 6
I tried using Delay_ms(500) before and after the EEprom_read(x) function. And when I tried doing the EEprom_read alone, I always read a value of 0x00, not 0xff. What could be the problem?


Top
 Profile  
 
 Post subject:
PostPosted: 23 Apr 2008 14:29 
Offline

Joined: 21 Oct 2005 23:04
Posts: 416
Location: Oslo, Norway
for (x = 0; x < 3u; x++) {

   reader = EEprom_Read(x);     // reader = 0xFF

   if (reader == 0) {           // reader will never be 0

      EEprom_Write(x, 10);      // So you never write anything

   }
}


Top
 Profile  
 
 Post subject:
PostPosted: 23 Apr 2008 14:43 
Offline

Joined: 22 Apr 2008 13:48
Posts: 6
No, when I do the EEprom_read(x) thing, reader gets a value of 0x00, not 0xFF. That's the problem. I am able to write after 1 iteration, but when x = 1, EEprom_read(1) contains 10, so it will not write anything. This is very basic, but I don't know what the problem is.

EDIT: Btw, this is done in MikroC simulator.


Top
 Profile  
 
 Post subject:
PostPosted: 23 Apr 2008 15:00 
Offline

Joined: 21 Oct 2005 23:04
Posts: 416
Location: Oslo, Norway
Winterburn wrote:
... I don't know what the problem is.


Winterburn wrote:
EDIT: Btw, this is done in MikroC simulator.


Winterburn wrote:
That's the problem


I think you did answer that question yourself :idea:


Top
 Profile  
 
 Post subject:
PostPosted: 23 Apr 2008 15:41 
Offline

Joined: 22 Apr 2008 13:48
Posts: 6
Why, is the MikroC Simulator not working on EEprom operations? That's kinda weird considering that it has EEPROM Editor.

I don't know why it doesn't iterate more than once, the source code seems ok to me, hence I told you that I don't know what other problem there might be. I don't care if it reads 0x00 or 0xFF, I'm just trying to verify my code, and why it's not iterating more than once. And even if I know what the problem is, I still don't know the solution for this, hence the topic started. :roll:


Top
 Profile  
 
 Post subject:
PostPosted: 23 Apr 2008 15:57 
Offline

Joined: 18 May 2005 00:59
Posts: 5465
Location: NYC
The EEPROM_WRITE() function has a wait state that tests the status of a register bit before moving on. This can only be managed real-time with the PIC under power. It might be possible to fake the status of the PIC's internal timeout through simulation.

You can manually change the status of this bit in the simulator and then your program will move forward.

Read the PIC datasheet about this conditional test required for EEPROM writes.

_________________
xor
CircuitED -


Top
 Profile  
 
 Post subject:
PostPosted: 23 Apr 2008 16:17 
Offline

Joined: 22 Apr 2008 13:48
Posts: 6
I saw the datasheet. It's EECON1, bit 2. It needs to be cleared on simulation to perform successive writes. But how about the value of the eeprom being 0x00 instead of 0xff by default? That's weird.


Top
 Profile  
 
 Post subject:
PostPosted: 23 Apr 2008 16:38 
Offline

Joined: 18 May 2005 00:59
Posts: 5465
Location: NYC
It's not weird, but likely a limitation of the simulator, or the choice of the designers in this case.

The simulator may not bother with EEPROM in much the same way it does not work with ADC functions. Simulation becomes more complicated because of flag bits and other issues that belong to real-world conditions inherent to the PIC. It is also the reason that ICD is very popular with some designers.

I have tested EEPROM functions and outputted to an LCD with no problem... running under power.

_________________
xor
CircuitED -


Top
 Profile  
 
 Post subject:
PostPosted: 23 Apr 2008 16:41 
Offline

Joined: 18 Feb 2006 13:17
Posts: 5124
Winterburn wrote:
Why, is the MikroC Simulator not working on EEprom operations? That's kinda weird considering that it has EEPROM Editor.
The software simulator does not emulate the processor fully. Even MPLAB does not do that. Simulated is execution of assembly instructions, but not the actions of processor peripherals, like EEPROM, USART, ADC, interrupts, timers, etc.

The EEPROM editor is an additional tool used for programming the processor, not to simulate EEPROM. If chosen, the contents of EEPROM editor window may be added to hex file, that's all.


Top
 Profile  
 
 Post subject:
PostPosted: 23 Apr 2008 16:49 
Offline

Joined: 22 Apr 2008 13:48
Posts: 6
I still simulated the same code, and found out that the reader = EEprom_read(x) returns the value under EEDATA, and not the one on the exact address pointed by x. So on the first iteration, x = 0x00, then passed to EEDATA, then on the write cycle, EEDATA becomes 10 (since it's a read/write data register), and so on the next read, EEDATA will be 10, and no other iteration will occur. I'm slowly figuring out the process! Yey!


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 13 posts ] 

All times are UTC + 1 hour


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: