CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

PIC16F876 v3.249 read_program_memory bug ??

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
prwatCCS



Joined: 10 Dec 2003
Posts: 67
Location: West Sussex, UK

View user's profile Send private message

PIC16F876 v3.249 read_program_memory bug ??
PostPosted: Mon Dec 11, 2006 4:37 pm     Reply with quote

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

View user's profile Send private message

PostPosted: Mon Dec 11, 2006 4:44 pm     Reply with quote

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








PostPosted: Mon Dec 11, 2006 5:01 pm     Reply with quote

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: 67
Location: West Sussex, UK

View user's profile Send private message

PostPosted: Mon Dec 11, 2006 5:08 pm     Reply with quote

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

View user's profile Send private message

PostPosted: Mon Dec 11, 2006 5:43 pm     Reply with quote

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: 67
Location: West Sussex, UK

View user's profile Send private message

PostPosted: Mon Dec 11, 2006 6:31 pm     Reply with quote

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

View user's profile Send private message

PostPosted: Mon Dec 11, 2006 6:38 pm     Reply with quote

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: 67
Location: West Sussex, UK

View user's profile Send private message

PostPosted: Mon Dec 11, 2006 6:50 pm     Reply with quote

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

View user's profile Send private message

PostPosted: Mon Dec 11, 2006 7:14 pm     Reply with quote

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: 67
Location: West Sussex, UK

View user's profile Send private message

PostPosted: Mon Dec 11, 2006 9:41 pm     Reply with quote

Many thanks

I know you dont work for CCS! All caveats taken on board.

regards
_________________
Peter Willis
Development Director
Howard Eaton Lighting Ltd UK
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
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