|
|
View previous topic :: View next topic |
Author |
Message |
prwatCCS
Joined: 10 Dec 2003 Posts: 70 Location: West Sussex, UK
|
PIC16F876 v3.249 read_program_memory bug ?? |
Posted: Mon Dec 11, 2006 4:37 pm |
|
|
I have a problem reading program memory from a PIC16F876, which is compiler version related ......
Compiler version 3.236 produces
Code: | .................... read_program_memory(0x02B2,RDMStringbuffer,32);
0710: MOVLW B2
0711: BSF 03.6
0712: MOVWF 0D << relevent location
0713: MOVLW 02
0714: MOVWF 0F << relevant location
0715: MOVLW 90
0716: MOVWF 04
0717: BSF 03.7
0718: MOVLW 20
0719: MOVWF 77
071A: INCF 77,F
071B: BCF 03.0
071C: RRF 77,F
071D: BSF 03.5
071E: BSF 0C.7
071F: BSF 0C.0
0720: NOP
0721: NOP
0722: BCF 03.5
0723: MOVF 0C,W
0724: MOVWF 00
0725: INCF 04,F
0726: MOVF 0E,W
0727: MOVWF 00
0728: INCF 04,F
0729: INCF 0D,F
072A: BTFSC 03.2
072B: INCF 0F,F
072C: DECFSZ 77,F
072D: GOTO 72F
072E: GOTO 731
072F: BSF 03.5
0730: GOTO 71F |
Compiler version 3.249
Code: | .................... read_program_memory(0x02B2,RDMStringbuffer,32);
0717: MOVLW 02
0718: BSF 03.6
0719: MOVWF 0E << relevant location (NOT!!)
071A: MOVLW B2
071B: MOVWF 0D << relevent location
071C: MOVLW 01
071D: BCF 03.6
071E: MOVWF 05
071F: MOVLW 90
0720: MOVWF 04
0721: BSF 03.7
0722: MOVLW 20
0723: BSF 03.5
0724: MOVWF 63
0725: BCF 03.5
0726: CALL 65D | ....................
....................
....................
You will note that complier version 3.236 places the source address in the correct locations as defined in the 16F876 datasheet, vis EEADR and EEADRH
UNFORTUNATELY, compiler version 3.249 has decided to place the source address high byte in 0x0E (in ram page 3) which is EEDATH rather than 0x0F EEADRH
Needless to say, you do not get the desired result.
Has anyone else seen this, or something similar ?
Given the various posts about version 4 of the CCS product, I am VERY reluctant to try and migrate to it, and yet I have code I need to release.
I already need to use v3.249 to solve other problems ... _________________ Peter Willis
Development Director
Howard Eaton Lighting Ltd UK |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Mon Dec 11, 2006 4:44 pm |
|
|
Can you post a short test program, complete with variable declarations,
#fuses, #use, and #include statements, that I can drop into MPLAB and
compile ? |
|
|
Guest
|
|
Posted: Mon Dec 11, 2006 5:01 pm |
|
|
You have done more work already, in trying to find the problem, than it'd take just to code your own version of this call....
Just generate it as a macro, so you can switch back when you have a working compiler. So something like:
Code: |
//At the start of your code to enable the fix
#define FIX_READ
#ifdef FIX_READ
#define read_program_memory(x,y,z) my_read_program_memory(x,y,z)
#byte EEDATA=0x10C
#byte EECON1=0x18C
#byte EECON2=0x18D
#byte EEADR=0x10DH
#byte EEADRH=0x10FH
#byte EEDATH=0x10EH
#bit EEPGD=EECON1.7
#bit WREN=EECON1.2
#bit RD=EECON1.0
#endif
void my_read_program_memory(int16 address, int8 * buffer, int8 count) {
while (count) {
EEADR=make8(address,0);
EEADRH=make8(address,1);
EEPGD=1;
RD=1;
*(buffer++)=EEDATA;
*(buffer++)=EEDATH;
if (count<2) count=0;
else count-=2;
address+=2;
}
}
|
No 'warranties', but this should be close to right.
Just undefine 'FIX_READ', to go back to using the standard code.
Best Wishes |
|
|
prwatCCS
Joined: 10 Dec 2003 Posts: 70 Location: West Sussex, UK
|
|
Posted: Mon Dec 11, 2006 5:08 pm |
|
|
Dear PCM programmer
Try compiling
Code: | #include <16F876.h>
#device adc=8
#FUSES NOWDT //No Watch Dog Timer
#FUSES
#use delay(clock=20000000)
void main()
{
char buffer[32];
setup_adc_ports(NO_ANALOGS);
setup_adc(ADC_OFF);
setup_spi(FALSE);
setup_timer_0(RTCC_INTERNAL|RTCC_DIV_1);
setup_timer_1(T1_DISABLED);
setup_timer_2(T2_DISABLED,0,1);
read_program_memory(0x02B8,buffer,32);
} |
under 3.236 and 3.249 and look at the code generated for read_program_memory().
This simple example exhibits the reported problem (at least on my system!!)
regards _________________ Peter Willis
Development Director
Howard Eaton Lighting Ltd UK |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Mon Dec 11, 2006 5:43 pm |
|
|
I tested it with both versions and I can confirm the bug. You're going
to have to use a work-around function, such as the one posted by Ttelmah. |
|
|
prwatCCS
Joined: 10 Dec 2003 Posts: 70 Location: West Sussex, UK
|
|
Posted: Mon Dec 11, 2006 6:31 pm |
|
|
Thanks for confirming the bug !!
I trust you have (like me) reported it to CCS in the vain hope that they might fix it in a v3.250
In fact I have recoded what I was trying to do , to use get_program_eeprom which does NOT exhibit the code bug, despite having the same interface to code reads!!
The storage mechanism for text strings is different for the PCM and PCH versions of the compiler, so this approach is only relevant to the 14bit parts.
The manual manipulation of the IRP bit is for when my Uart buffer is in ram page 2 or 3 and I am not using #device *=16
Code: | //
// This code gets strings stored as a sequence of RETLW instructions and places them as text in the Uart Buffer
//
//
u8 get_ROM_StringtoUartBuffer (u16 address, u8 offset)
{
u8 opcode;
u8 asciichar;
u16 result16;
do
{
result16 = read_program_eeprom(address);
opcode = make8(result16,1);
asciichar = make8(result16,0);
#ifdef UartBuff_PAGE_RAM
bit_set(STATUSREG,IRP);
#endif
UartBuff.MsgHdr.ParameterData[offset] = asciichar;
#ifdef UartBuff_PAGE_RAM
bit_clear(STATUSREG,IRP);
#endif
offset++;
address++;
} while ((opcode == RETLWCODE1 ) && (asciichar != 0x00));
UartBuff.MsgHdr.ParameterData[offset] = 0x00; //make sure buffer is NULL terminated
// check that ROM contains a formatted string with RETLW code
return(offset);
} |
regards _________________ Peter Willis
Development Director
Howard Eaton Lighting Ltd UK |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Mon Dec 11, 2006 6:38 pm |
|
|
Quote: | I trust you have (like me) reported it to CCS in the vain hope that they might fix it in a v3.250 |
I haven't reported it. I don't think there will be a vs. 3.250.
CCS is only working on vs. 4 of the compiler. |
|
|
prwatCCS
Joined: 10 Dec 2003 Posts: 70 Location: West Sussex, UK
|
|
Posted: Mon Dec 11, 2006 6:50 pm |
|
|
From what I read on this forum, v4 needs all the help they can give it and more.
Is it anywhere near stable enough to consider yet ?
Are you in a position to try my read_program_memory issue out on v4 ?
regards _________________ Peter Willis
Development Director
Howard Eaton Lighting Ltd UK |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Mon Dec 11, 2006 7:14 pm |
|
|
Quote: | Are you in a position to try my read_program_memory issue out on v4 ? |
I tested it with PCM vs. 4.017 and it appears to work OK.
Here is the output from the test program shown below:
Quote: |
Start:
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
|
However, remember there is no guarantee that other
parts of your program will work with the new version.
I just tested this one part for you. I don't work for
CCS and I'm just trying to help you on this one aspect
of your program.
Code: |
#include <16F876.H>
#fuses HS, NOWDT, PROTECT, BROWNOUT, PUT, NOLVP
#use delay(clock=20000000)
#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7, ERRORS)
#rom int8 0x2B8 = {
0,1,2,3,4,5,6,7,8,9,
10,11,12,13,14,15,16,17,18,19,
20,21,22,23,24,25,26,27,28,29,30,31}
//===============================
void main()
{
int8 i;
int8 buffer[32];
printf("Start:\n\r");
read_program_memory(0x02B8,buffer,32);
for(i=0; i < 32; i++)
printf("%X ", buffer[i]);
while(1);
} |
|
|
|
prwatCCS
Joined: 10 Dec 2003 Posts: 70 Location: West Sussex, UK
|
|
Posted: Mon Dec 11, 2006 9:41 pm |
|
|
Many thanks
I know you dont work for CCS! All caveats taken on board.
regards _________________ Peter Willis
Development Director
Howard Eaton Lighting Ltd UK |
|
|
|
|
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 vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|