You can store the information couple different ways other than eeprom. If using constants then the Lookup Table would work. If storing variable values then the PIC has self write to flash ability. Try the ProgramWrite command from Help. If that doesn't work, then I have working code that i could post for the 10f322.
EDIT: Oops, make that a 10f322 not 12f322
Last edit: kent_twt4 2015-03-12
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am trying to store variables values. I tried the ProgramWrite command and it does not work either. My problem can be easily replicated with the simple following program:
;Chip Settings
#chip 16F1509
dim loca,test as Word
loca=1
test=loca
ProgramWrite(loca,test)
It compiles ok but when then assembled I get a similar error message:
Errors have been found:
Error: GCASM: Symbol EEADDRESS has not been defined
Error: GCASM: Symbol EEADDRESS_H has not been defined
Error: GCASM: Symbol EEDATAWORD has not been defined
Error: GCASM: Symbol EEDATAWORD_H has not been defined
The message has been logged to the file Errors.txt.
And when you look at the .asm file you can see that the code generated by the ProgramWrite statement is:
O.K. so here goes my port from the data sheet from a couple of years ago. Found out I got this working for 12f1822, so that's good. All I'm doing here is writing a word variable, with two seperate Byte variables (Group and GroupModes)) as simulated eeprom to address 0x7F0, easily checked by PICKit 2 Program Memory window. Then the flash memory address is read and then sent along via hardware UART to alternate TX pin to read out on a terminal.
Have left some assembly instructions here and there, which were a product of a partial GCB port.
Hope this works for you. You will have to setup passing parameters to the procedures as you need. This was strictly the test case, which works without regard to full blown header file.
'Test for programming flash memory
'Kent Schafer 3/11/2015
#chip 12f1822,4
#config OSC= INTOSC
'******Program Memory Write*******
Group = 5
GroupModes = b'01010100'
AddrL = 0xF0 'MUST START ON X0h OR ZERO ROW VALUE??
AddrH = 0x07
'Prog_Addr_Lo = AddrL
'Prog_Addr_Hi = AddrH
Call EraseRow
'ADDRL = 0xF8
'Call EraseRow
AddrL = 0xF0
Call WriteRow
'ADDRL = 0xF8
Call WriteRow
Prog_Addr_Lo = 0xF0
Prog_Addr_Hi = 0x07
Call ReadWord
test = Prog_Data_Lo
GroupMode_Data = 0
'******USART**********
#define USART_BAUD_RATE 9600
#define USART_BLOCKING
TXCKSEL = 1 'TX on RA4
dir PortA.4 out
Main:
HSerPrint "hello"
bin2ascii Prog_Data_Hi 'return values from ReadRow
bin2ascii Prog_Data_Lo 'At addr 7F0 value is 0x0554 or 584 Dec.
wait 2 s
goto Main
sub ReadWord
;* This code block will read 1 word of program
;* memory at the memory address:
;PROG_ADDR_HI : PROG_ADDR_LO
;* data will be returned in the variables;
;* PROG_DATA_HI, PROG_DATA_LO
EEADRH = PROG_Addr_HI
EEADRL = PROG_Addr_LO
CFGS = 0
EEPGD = 1
GIE = 0
RD = 1
NOP ; Executed (Figure 11-1)
NOP ; Ignored (Figure 11-1)
GIE = 1
Prog_Data_Lo = EEDATL
Prog_Data_Hi = EEDATH
end sub
sub WriteRow
; This write routine assumes the following:
; 1. The 16 bytes of data are loaded, starting at the address in DATA_ADDR
; 2. Each word of data to be written is made up of two adjacent bytes in DATA_ADDR,
; stored in little endian format
; 3. A valid starting address (the least significant bits = 000) is loaded in ADDRH:ADDRL
; 4. ADDRH and ADDRL are located in shared data memory 0x70 - 0x7F
;
GIE = 0
EEADRL = ADDRL
EEADRH = ADDRH
EEPGD = 1
CFGS = 0
WREN = 1
LWLO = 1
NextLatch:
EEDATL = GroupModes 'WORKS!!!!
EEDATH = Group
MOVF EEADRL,W ; Check if lower bits of address are '000'
XORLW 0x07 ; Check if we're on the last of 8 addresses
ANDLW 0x07 ;
BTFSC STATUS,Z ; Exit if last of eight words,
GOTO START_WRITE ;
EECON2 = 0x55
EECON2 = 0xAA
WR = 1
NOP ; Any instructions here are ignored as processor
; halts to begin write sequence
NOP ; Processor will stop here and wait for write to complete.
; After write processor continues with 3rd instruction.
INCF EEADRL,F ; Still loading latches Increment address
GOTO NextLatch ; Write next latches
START_WRITE:
LWLO = 0
EECON2 = 0x55
EECON2 = 0xAA
WR = 1
NOP ; Any instructions here are ignored as processor
; halts to begin write sequence
NOP ; Processor will stop here and wait for write complete.
; after write processor continues with 3rd instruction
BCF EECON1,WREN ; Disable writes
BSF INTCON,GIE ; Enable interrupts
end sub
sub EraseRow
; This row erase routine assumes the following:
; 1. A valid address within the erase block is loaded in ADDRH:ADDRL
; 2. ADDRH and ADDRL are located in shared data memory 0x70 - 0x7F
GIE = 0
EEADRL = ADDRL
EEADRH = ADDRH
EEPGD = 1
CFGS = 0
FREE = 1
WREN = 1
EECON2 = 0x55
EECON2 = 0xAA
WR = 1
NOP ; Any instructions here are ignored as processor
; halts to begin erase sequence
NOP ; Processor will stop here and wait for erase complete.
; after erase processor continues with 3rd instruction
WREN = 0
GIE = 1
end sub
sub bin2ascii (LCDValue) #NR
LCDValueTemp = 0
LCDShowChar = 0
SERCEN = 0
SERDEC = 0
SERUN = 0
If LCDValue >= 100 then
LCDValueTemp = LCDValue / 100
LCDValue = SysCalcTempX
SERCEN = LCDValueTemp + 48
HSerSend SERCEN
LCDShowChar = TRUE
End If
If LCDShowChar > 0 or LCDValue >= 10 then
LCDValueTemp = LCDValue / 10
LCDValue = SysCalcTempX
SERDEC = LCDValueTemp + 48
HSerSend SERDEC
End If
SERUN = LCDValue + 48
HSerSend SERUN
End Sub
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for your help Kent!
Your solution is a bit too techie for me :-) but I found an easier one...
I replaced gcbasic.exe with the latest version provided by Hugh in this post and it seems that the issue is being solved in the upcoming release. EPRead and EPWrite seem to work for this chip (I have not checked with "real" 1509 chip yet but my program is now assembled flawlessly and run without any problem under Proteus (at least if you load the Hex file, since the asm one does not compile ok under MPLAB ASM :-( )
Last edit: Jacques Nilo 2015-03-13
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My program (which works fine with a 16F690) compiles ok but when assembling I get the following message:
Assembling program ...
Errors have been found:
Error: GCASM: Symbol EEADDRESS has not been defined
Error: GCASM: Symbol EEDATAVALUE has not been defined
I cannot find EEADR nor EEDATH in the 16F1509.dat file. Could that be the problem ?
Jacques
Apparently No EEPROM memory in 16F1509, but Flash Memory. If that is the problem does it mean it is not possible to store data in permanent memory ?
You can store the information couple different ways other than eeprom. If using constants then the Lookup Table would work. If storing variable values then the PIC has self write to flash ability. Try the ProgramWrite command from Help. If that doesn't work, then I have working code that i could post for the 10f322.
EDIT: Oops, make that a 10f322 not 12f322
Last edit: kent_twt4 2015-03-12
I am trying to store variables values. I tried the ProgramWrite command and it does not work either. My problem can be easily replicated with the simple following program:
It compiles ok but when then assembled I get a similar error message:
And when you look at the .asm file you can see that the code generated by the ProgramWrite statement is:
It is refering to variables - EEADDRESS,EEDATAWORD - that are undeclared in the alias variables section of the code.
Jacques
O.K. so here goes my port from the data sheet from a couple of years ago. Found out I got this working for 12f1822, so that's good. All I'm doing here is writing a word variable, with two seperate Byte variables (Group and GroupModes)) as simulated eeprom to address 0x7F0, easily checked by PICKit 2 Program Memory window. Then the flash memory address is read and then sent along via hardware UART to alternate TX pin to read out on a terminal.
Have left some assembly instructions here and there, which were a product of a partial GCB port.
Hope this works for you. You will have to setup passing parameters to the procedures as you need. This was strictly the test case, which works without regard to full blown header file.
Thanks for your help Kent!
Your solution is a bit too techie for me :-) but I found an easier one...
I replaced gcbasic.exe with the latest version provided by Hugh in this post and it seems that the issue is being solved in the upcoming release. EPRead and EPWrite seem to work for this chip (I have not checked with "real" 1509 chip yet but my program is now assembled flawlessly and run without any problem under Proteus (at least if you load the Hex file, since the asm one does not compile ok under MPLAB ASM :-( )
Last edit: Jacques Nilo 2015-03-13