 |
 |
| View previous topic :: View next topic |
| Author |
Message |
treitmey
Joined: 23 Jan 2004
Posts: 1094
Location: Appleton,WI USA
|
| Another pair of eyes |
 Posted: Fri Dec 16, 2005 12:08 pm |
 |
|
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
|
|
| Posted: Fri Dec 16, 2005 12:31 pm |
|
|
| 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
|
|
| Posted: Fri Dec 16, 2005 12:50 pm |
|
|
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
|
|
| Posted: Fri Dec 16, 2005 1:12 pm |
|
|
| 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
|
|
| Posted: Fri Dec 16, 2005 2:31 pm |
|
|
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
|
|
| Posted: Fri Dec 16, 2005 2:46 pm |
|
|
| 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
|
|
| Posted: Fri Dec 16, 2005 3:12 pm |
|
|
| 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
|
|
| Posted: Sun Dec 18, 2005 1:42 pm |
|
|
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
|
|
| Posted: Mon Dec 19, 2005 3:46 am |
|
|
| 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
|
|
| Posted: Mon Dec 19, 2005 3:47 am |
|
|
| 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
|
|
| Posted: Mon Dec 19, 2005 5:07 am |
|
|
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?  |
|
|
Mark
Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA
|
|
| Posted: Mon Dec 19, 2005 8:29 am |
|
|
| 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
|
|
| Posted: Mon Dec 19, 2005 8:29 am |
|
|
| 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
|
|
| Posted: Mon Dec 19, 2005 10:15 am |
|
|
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
|
|
| Posted: Mon Dec 19, 2005 4:00 pm |
|
|
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. |
|
|
|
|
|
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
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
