| View previous topic :: View next topic |
| Author |
Message |
tonymcc
Joined: 27 Jul 2010
Posts: 15
Location: Northampton UK Home of the 'Big Sheds'
|
| 18F4620 internal eeprom - PCW 4.116 ICD-U64 Clock 8MHz |
 Posted: Tue Jan 18, 2011 8:00 am |
 |
|
I have spent a morning wrestling with saving and restoring 18 16bit calibration constants in a t/c scanner I am developing. I came across three unexpected requirements.
1) Address has to be declared as int16. This usually means writing something like this for a typical finite loop
write_eeprom((int16) (address calculation),data)
the declaration has to be local. Same for the read.
2) Whilst testing I found that I had to have a delay above 2mS between writes and reads to the eeprom. This is not a problem in the application but it certainly wasted time discovering this during simple write to read interactive tests.
3)The eeprom appears to get wiped during loading prior to debugging by the ICD-U64. This didn't happen when I have been playing around recently with a 24FJ128GA010 device. Eeprom data would remain across power downs and re-loading during debugging using a similar development setup as above.
I would appreciate any comments on the above as I have probably missed something obvious. Cheers. |
|
 |
gpsmikey
Joined: 16 Nov 2010
Posts: 588
Location: Kirkland, WA
|
|
| Posted: Tue Jan 18, 2011 9:32 am |
|
|
I have not used the ICD-U64, but at least with the PicKit2 programmer, there is an option check box to select if the data eeprom gets written to during programming etc.
mikey
_________________
mikey
-- you can't have too many gadgets or too much disk space !
old engineering saying: 1+1 = 3 for sufficiently large values of 1 or small values of 3 |
|
|
dbotkin
Joined: 08 Sep 2003
Posts: 197
Location: Omaha NE USA
|
|
| Posted: Tue Jan 18, 2011 3:25 pm |
|
|
Odd, I'm using the 18F4620 and seeing none of those issues. My EEPROM address value is int8 and I have not added any delays since updating to 4.116.
Maybe posting your code would be helpful, it doesn't sound to me like a compiler issue. |
|
|
tonymcc
Joined: 27 Jul 2010
Posts: 15
Location: Northampton UK Home of the 'Big Sheds'
|
|
| Posted: Wed Jan 19, 2011 5:08 am |
|
|
Thanks for the response. The second point regarding the timing between writes and reads is really trivial as you would never do this in an application but it is the first test you would do if you suspected trouble with the eeprom.
The segment of code for write and read of the eeprom is:
| Code: |
void store_cal (void) //store calibration information
{ unsigned int8 i;
unsigned int8 low_byte;
unsigned int8 high_byte;
for(i=0; i<18; ++i)
{ high_byte = cal_val[i] >>8;
low_byte = cal_val[i] & 0x00FF;
write_eeprom((int16)(i*2),high_byte);
delay_ms(3);
write_eeprom((int16)((i*2)+1),low_byte);
delay_ms(3);
}
}
void get_cal (void) //restore calibration information
{ unsigned int8 i;
unsigned int8 low_byte;
unsigned int8 high_byte;
for(i=0; i<18; ++i)
{ high_byte = read_eeprom((int16) i * 2);
delay_ms(3);
low_byte = read_eeprom((int16) ((i * 2) + 1));
delay_ms(3);
cal_val[i] = make16(high_byte,low_byte);
}
}
|
I left the delays in just in case. Timing is not critical in the application so it was just belt and braces, as was disabling interrupts during the use of store_cal in my main routine.
| Code: |
void one_point(unsigned int8 num) //action at one point
{
do
{ query_hold(); //check for hold display at point
rst_trip(num); //scan for attempts to reset the trip at this point
if(int_counter==0) //check every second
{ read_all(); //read all t/c's
print_chan_num(num); //display pointed channel
}
if(calsw()) //check calibration required
{ while(calsw()); //cal switch unpress
disable_interrupts(INT_TIMER1); //Disable the interrupt during calibration
lcd_clear(); //clear display
cal_sequence(); //run through all calibration steps
store_cal(); //store calibration in EEPROM
enable_interrupts(INT_TIMER1); //enable port interrupt
enable_interrupts(GLOBAL); //global interrupts
}
if(hold_flag==1) //if flag is toggled true - i.e no hold required
set_scan_time();
}
while(!scan_time_running==0);
}
|
The clearing of the eeprom during debug loads is still a mystery. I can program the device via CCSLOAD and fill the data eeprom during a calibration sequence and it will operate happily, retaining values over power downs. There doesn't seem to be any options in the debugger window to protect the data eeprom during ROM programming. In CCSLOAD, I can prevent erasure of the existing eeprom data, set during debug, during final ROM programming.
When I have used ICD2 and MPLAB when programming in assembler, it was possible to export and import the data eeprom .hex files, very useful for setting specific environments for applications. The CCS product doesn't seem to have this feature. Again, any comments would be useful. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
