 |
 |
| View previous topic :: View next topic |
| Author |
Message |
mpfj
Joined: 09 Sep 2003
Posts: 95
Location: UK
|
| Bug in string printing ... 3v186 |
 Posted: Tue Mar 02, 2004 5:36 am |
 |
|
Device = PIC18F8720
I've just reported the following bug to CCS ...
| Quote: | | Code: | void write_char(char c) {
// dummy statement to ensure routine is used
c++;
}
void main() {
int8 i = 0;
write_char(text[i]);
}
|
Problem
When passing a string to a function taking a char as its parameter (i.e. your virtual "print string" implementation), the TBLPTRH register is not updated correctly.
Although the register is initialised okay, when the index value is incremented after calling the lookup code, only the least significant byte is incremented, thus limiting the lookup to the first 256 bytes.
| Code: | 0210: CLRF 0B <- 0x0B holds the index MSB
0212: MOVFF 09,0A <- 0x0A holds the index LSB
0216: MOVFF 0B,FF7 <- index MSB placed in TBLPTRH register
021A: MOVF 0A,W <- index LSB placed in WREG
021C: CALL 0004 <- call to table lookup code
0220: IORLW 00
0222: BTFSC FD8.2
0224: GOTO 0234
0228: INCF 0A,F <- index LSB incremented, but not the MSB !!!
022A: MOVWF 0B <- index MSB now corrupted
022C: GOTO 01E0 <- call to "print character" routine
0230: GOTO 0216 <- loop
|
As you can see, on line 0x228, the index LSB is incremented, but the index MSB is not updated with any carry overflow.
You will also notice that the index MSB register is used to pass the value to the "print character" routine, thus corrupting the index value !!
|
These bugs are coming thick and fast !!!
Mark |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Tue Mar 02, 2004 11:20 am |
|
|
I normally use PCM for most projects, so I don't watch PCH problems
that much. But currently, we are doing a project using PCH 3.178.
I notice you're finding a lot of Table Read bugs. Do you think these
are just in the most recent versions, or were they in earlier versions ?
Is PCH 3.178 safe ? We will be building a few hundred units.
If there is some doubt about it, I'm going to have to test it for
all these bugs. |
|
|
Ttelmah
Guest
|
|
| Posted: Tue Mar 02, 2004 11:41 am |
|
|
| PCM programmer wrote: | I normally use PCM for most projects, so I don't watch PCH problems
that much. But currently, we are doing a project using PCH 3.178.
I notice you're finding a lot of Table Read bugs. Do you think these
are just in the most recent versions, or were they in earlier versions ?
Is PCH 3.178 safe ? We will be building a few hundred units.
If there is some doubt about it, I'm going to have to test it for
all these bugs. |
Historically, PCH, had a lot of problems in the early 3.xxx versions. By about 3.14x, 90% had been fixed, and code that had previously worked on the 16 chips would now work without too much work on the 18 chips. There have since been a number of changes to the development enviroment, and the development tools, and a whole new 'crop' of bugs seem suddenly to have arisen in areas that were working before. I partially suspect that CCS, are trying to get some of the things that still had problems 'fixed', and are creating new faults. Though the 18 family, should not have the limits on array sizes etc., that applied to the 16 family, in some areas they still seemed to remain in place (with odd problems appearing in larger structures). I think this is why they are 'fiddling' here.
It is perhaps indicative that they still have 3.148 showing (which was one of the first versions that worked pretty well for me).
If you don't mind the older enviroment, I'd stay with this version.
Best Wishes |
|
|
Chas
Guest
|
|
| Posted: Tue Mar 02, 2004 11:56 am |
|
|
| All variables in your example are 8 bits (int8 an char). Thus you can not have more than 256 entries in your tables. Have you tried changing your index or other variable to a long to see if this changes the generated assembly code? |
|
|
mpfj
Joined: 09 Sep 2003
Posts: 95
Location: UK
|
|
| Posted: Wed Mar 03, 2004 3:38 am |
|
|
True, all my variables are 8bit, but I'm not really using these as the index value. I'm legitimately relying on the compiler to sort out the index offsets of my string array.
I *should* be able to define the following ...
char text[2][200] = {...};
... which creates 2 x 200 character strings. Both dimensions are 8bit, but obviously the compiler needs to *automatically* convert this into a 16bit offset, since the whole array is > 256 bytes. |
|
|
|
|
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
