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

Another pair of eyes
Goto page 1, 2  Next
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
treitmey



Joined: 23 Jan 2004
Posts: 1094
Location: Appleton,WI USA

View user's profile Send private message Visit poster's website

Another pair of eyes
PostPosted: Fri Dec 16, 2005 12:08 pm     Reply with quote

Would someone look at this function to look for an error.
Its a bootloader that has the prgm stored(memory mapped) in fram prior to the call. The function reads fram (I2C) and programs it to the PIC

It looks like it works,.. But the printf of the version number isn't increasing as expected.
Code:
//===================== PrgmPIC =========================
#org 0x7A00, 0x7FC0
void PrgmPIC(void){
  int32 address=0,size,offset;
  int8 data;
  int16 cnt;
 
  char *ptr_char;
  disable_interrupts(GLOBAL);
  for(address=0;address<32768;address+=256){ //read 256bytes prgm from fram
    ptr_char=&RX_BUF[0];//defined as global. char RX_BUF[256];
    for(size=256;size;ptr_char++,size--){
      if(size==256){
        i2c_start();
        i2c_write((0xA0|(int8)(address>>14))&0xFE);//&0xFE forces to write
        i2c_write(hi(address));
        i2c_write(lo(address));
        i2c_start();
        i2c_write((0xA0|(int8)(address>>14))|1);//|1 forces to read
      }
      if(size==1)
      {
        *ptr_char=i2c_read(0);//No ack on last read of chip
        i2c_stop();
      }
      else
      {
        *ptr_char=i2c_read(1);//The ack will put next data on bus
      }
    }
//    for (offset=0;offset<256;offset++){//write 256bytes in 4 writes. offset=0,64,128,192
//      //write_program_memory(address+offset,&RX_BUF[0],64);//erase=64,write=8
//      //fprintf(DEBUG,"%X ",RX_BUF[offset]);
//      fputc(RX_BUF[offset],DEBUG);
//    }

    for (offset=0;offset<256;offset+=64){//write 256bytes in 4 writes. offset=0,64,128,192
      write_program_memory(address+offset,&RX_BUF[offset],64);//erase=64,write=8
      //fprintf(DEBUG,"%lu ",address+offset);
    }
  }
  //Clear the first 5 locations in fram, Setting to factory default 0xFF
  address=0;size=5;data=0xFF;
  i2c_start();
  i2c_write((0xA0|(int8)(address>>14))&0xFE);
  i2c_write(hi(address));
  i2c_write(lo(address));
  for(;size;size--,address++){
    i2c_write(data);
  }
  i2c_stop();
  fprintf(DEBUG,"Done\n\r");
  reset_cpu();
}
Chas
Guest







PostPosted: Fri Dec 16, 2005 12:31 pm     Reply with quote

I don't have access to my compiler or the help, and I haven't used these functions, but you have address declared as int32, but you are using the hi() and lo() functions. I thought that these were for accessing the high and low bytes of an int16. Do these functions work as intended for int32?
treitmey



Joined: 23 Jan 2004
Posts: 1094
Location: Appleton,WI USA

View user's profile Send private message Visit poster's website

PostPosted: Fri Dec 16, 2005 12:50 pm     Reply with quote

Yes, I think these should work on int32.
Its should be giving me byte0 for the lo and byte1 for hi


#define hi(x) (*(&x+1)) //data held at addr of x + 1
#define lo(x) (*(&x)) //data held at addr of x

------
You can see a commented out section where I was printing the data.

Looked to compair well with the hex file.
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Fri Dec 16, 2005 1:12 pm     Reply with quote

Quote:

It looks like it works,.. But the printf of the version number isn't
increasing as expected.
You can see a commented out section where I was printing the data.

Can you explain where the version number is ? Can you re-post
a segment of the code above and indicate the line where it's failing ?
Post what you expect the data to be, and what you're actually seeing.
treitmey



Joined: 23 Jan 2004
Posts: 1094
Location: Appleton,WI USA

View user's profile Send private message Visit poster's website

PostPosted: Fri Dec 16, 2005 2:31 pm     Reply with quote

A simple define and a fprintf.
I will change FIRM_MINOR to 06 and recompile,upload,... yet 06 won't show up on DEBUG.
btw. I based my I2C fram reading from tested code. ((library FM24C256))
-----much code removed for clarity-----
Code:

//=======================//
#define  FIRM_MAJOR  2
#define  FIRM_MINOR  05
#define  HARD_MAJOR  3
#define  HARD_MINOR  01
#define  PROD_ID     1
#include <18f452.h>
#include <3200i.h>

#fill_rom 0xFFFF
#org 0x7986, 0x79FF  //Adjust 0x7986 to get numbers to line up at 0x79A0
const char revision[] = {FIRM_MAJOR,FIRM_MINOR,HARD_MAJOR,HARD_MINOR,PROD_ID};
/////////////////////////////////////////////////////////////////////
//#define SCREEN_SAVE TRUE
#define SCREEN_SAVE FALSE
//#define TEMP_SENSOR TRUE
#define TEMP_SENSOR FALSE
/////////////////////////////////////////////////////////////////////
void Initial_Setup(void);
//---------------- MAIN --------------------
void main(void){
  int8 key;
  Initial_Setup();  // Do the prelim setup of LCD timers, ect..
  while(1){
  }//end while(1)
}//end main

//////////////////////////////////////////////////////////////
////////////////////// Functions /////////////////////////////
//////////////////////////////////////////////////////////////
//==================Initial_Setup=====================//
void Initial_Setup(void){
  int16 cnt;
  disable_interrupts(GLOBAL);
  setup_adc_ports(NO_ANALOGS);
  //tz.dow[2].start=1440;//wed start time
  //inv_display=!input(PIN_B3);
  //fprintf(DEBUG,"INV=%u\n\r",inv_display);
  //MyAddr=input_a();//needs to be before 485init, it is used in msg chksum calculation
  MyAddr=0;//needs to be before 485init, it is used in msg chksum calculation
  fprintf(DEBUG,"STARTING\n\r");
  fprintf(DEBUG,"MYADDR=%U\n\r",MyAddr);
  fprintf(DEBUG,"FIRMWARE VERSION %u.%02u\n\r",FIRM_MAJOR,FIRM_MINOR);
}

DragonPIC



Joined: 11 Nov 2003
Posts: 118

View user's profile Send private message

PostPosted: Fri Dec 16, 2005 2:46 pm     Reply with quote

treitmey wrote:
Yes, I think these should work on int32.
Its should be giving me byte0 for the lo and byte1 for hi


#define hi(x) (*(&x+1)) //data held at addr of x + 1
#define lo(x) (*(&x)) //data held at addr of x

------
You can see a commented out section where I was printing the data.

Looked to compair well with the hex file.


It might not be as portable to other compilers but I like to use:
int32 address;
#byte address1 = address + 1
#byte address2 = address + 2
#byte address3 = address + 3
_________________
-Matt
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Fri Dec 16, 2005 3:12 pm     Reply with quote

Quote:
#define FIRM_MAJOR 2
#define FIRM_MINOR 05
#define HARD_MAJOR 3
#define HARD_MINOR 01
fprintf(DEBUG,"FIRMWARE VERSION %u.%02u\n\r",FIRM_MAJOR,FIRM_MINOR);

These are constants. They not being read from an array or eeprom.
They're hardcoded into the setup code for that fprintf() statement
at compile time. So if you're not seeing the proper version numbers
displayed, it could be:

1. The new version of code is not really being compiled.

2. The HEX file for the new version is not being created in or
taken from the directory that you think it's in.

3. The HEX file is not really being downloaded and flashed to the PIC.

4. The routine that displays these numbers is not really being called.
Another routine is being called instead.
treitmey



Joined: 23 Jan 2004
Posts: 1094
Location: Appleton,WI USA

View user's profile Send private message Visit poster's website

PostPosted: Sun Dec 18, 2005 1:42 pm     Reply with quote

I've checked the list and hex files. They are there, and look as though the code(version number in printf) changes in lock step. This MUST?? be that it really isn't getting programmed.

which leads me to the programming part. I've done a printf to a debug terminal of the FRAM and it checks out to the HEX. Soo... Then the problem must lie in the write_program_memory. But I can't figure it out.


Funny thing is.. I checked a simple version of this doing 1 byte write_program_memory. and a little tinny hex prgm. It worked. But this bigger ((full production code)) doing the 8,16,64((tried them all)) doesn't work. I guess I'll drop back and punt [as my father would say] i try again little steps and see where it dies. back to 1 byte and tinny programs.
JPA
Guest







PostPosted: Mon Dec 19, 2005 3:46 am     Reply with quote

treitmey wrote:
Yes, I think these should work on int32.
Its should be giving me byte0 for the lo and byte1 for hi


#define hi(x) (*(&x+1)) //data held at addr of x + 1
#define lo(x) (*(&x)) //data held at addr of x


Hello,

I think that, if x is an int32, then &x is a pointer to int32. So &x+1 points to the next int32, that is 4 bytes address more.

When I have to extract bytes from int16 or int32, I uses the make8 function.
JPA
Guest







PostPosted: Mon Dec 19, 2005 3:47 am     Reply with quote

treitmey wrote:
Yes, I think these should work on int32.
Its should be giving me byte0 for the lo and byte1 for hi


#define hi(x) (*(&x+1)) //data held at addr of x + 1
#define lo(x) (*(&x)) //data held at addr of x


Hello,

I think that, if x is an int32, then &x is a pointer to int32. So &x+1 points to the next int32, that is 4 bytes address more.

When I have to extract bytes from int16 or int32, I uses the make8 function.
Storic



Joined: 03 Dec 2005
Posts: 182
Location: Australia SA

View user's profile Send private message Send e-mail

PostPosted: Mon Dec 19, 2005 5:07 am     Reply with quote

just a question
if
Code:

#define lo(x) (*(&x)) //data held at addr of x + 0
#define hi(x) (*(&x+1)) //data held at addr of x + 1
is correct,
Can i then assume
Code:

#define higher(x) (*(&x+2)) //data held at addr of x + 2
#define highest(x) (*(&x+3)) //data held at addr of x + 3
will be also correct

and will this cater for all of the bytes of int32 (4 lots of 8 bits)

ANdrew
_________________
What has been learnt if you make the same mistake? Wink
Mark



Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA

View user's profile Send private message Send e-mail

PostPosted: Mon Dec 19, 2005 8:29 am     Reply with quote

JPA wrote:
treitmey wrote:
Yes, I think these should work on int32.
Its should be giving me byte0 for the lo and byte1 for hi


#define hi(x) (*(&x+1)) //data held at addr of x + 1
#define lo(x) (*(&x)) //data held at addr of x


Hello,

I think that, if x is an int32, then &x is a pointer to int32. So &x+1 points to the next int32, that is 4 bytes address more.

When I have to extract bytes from int16 or int32, I uses the make8 function.


&x is not a pointer but rather an address. So what he has is correct.
Mark



Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA

View user's profile Send private message Send e-mail

PostPosted: Mon Dec 19, 2005 8:29 am     Reply with quote

Storic wrote:
just a question
if
Code:

#define lo(x) (*(&x)) //data held at addr of x + 0
#define hi(x) (*(&x+1)) //data held at addr of x + 1
is correct,
Can i then assume
Code:

#define higher(x) (*(&x+2)) //data held at addr of x + 2
#define highest(x) (*(&x+3)) //data held at addr of x + 3
will be also correct

and will this cater for all of the bytes of int32 (4 lots of 8 bits)

ANdrew

Yes
treitmey



Joined: 23 Jan 2004
Posts: 1094
Location: Appleton,WI USA

View user's profile Send private message Visit poster's website

PostPosted: Mon Dec 19, 2005 10:15 am     Reply with quote

Reviewing my list file I see the I2C read,write,start,stop do a call to the non-protected and non #org'd area. Is there a way to #org these too?
Or do I have to roll-my-own?

How do I get the I2C routines into the #org'd space?
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Mon Dec 19, 2005 4:00 pm     Reply with quote

The manual says:

Quote:
#ORG start,end DEFAULT
or
#ORG DEFAULT

If the keyword DEFAULT is used then this address range is
used for all functions user and compiler generated from this
point in the file until a #ORG DEFAULT is encountered (no
address range). If a compiler function is called from the
generated code while DEFAULT is in effect the compiler
generates a new version of the function within the specified
address range.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Goto page 1, 2  Next
Page 1 of 2

 
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