From: Peter C. <pe...@pe...> - 2006-10-07 13:31:07
|
Chaps, I'm getting the following error from gpsim and the code does not work on a= =20 PIC. My suspicion is that my variables have run out of file registers or=20 are attempting to overright ones they should not. I'm attemping to write=20 code for the PIC 16F877. Any hints? =46rom GPSIM, as it stops: attempt write to invalid file register address 0x90, value 0xff 0x0000000004C61337 0x08EB 0x0090 movwf _T1CON_bits Pete |
From: Scott D. <sc...@da...> - 2006-10-07 15:16:07
|
> Chaps, > > I'm getting the following error from gpsim and the code does not work on a > PIC. My suspicion is that my variables have run out of file registers or > are attempting to overright ones they should not. I'm attemping to write > code for the PIC 16F877. > > Any hints? > >>From GPSIM, as it stops: > > attempt write to invalid file register > address 0x90, value 0xff > 0x0000000004C61337 0x08EB 0x0090 movwf _T1CON_bits Pete, I'm really pleased to see that you're using gpsim for your development! The reason gpsim halted is because address 0x90 is invalid for the 16F877. The T1CON register (which I assume you're attempting to address) is at address 0x10. So the problem is that your bank register is incorrect; your pointing into bank 01 when you should be pointing into bank 00. I don't know if the offending code was written by you or SDCC, but in either case you may track down where the bank was (or was not) getting written by using gpsim's trace command. For example, you can say 'trace 100' to see what has happened for the last 100 instruction cycles. This will allow you to inspect where things went awry. Scott > > Pete > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > > |
From: Peter C. <pe...@pe...> - 2006-10-07 18:52:20
|
On Saturday 07 October 2006 16:13, Scott Dattalo wrote: > > I'm really pleased to see that you're using gpsim for your development! > Not as pleased as I am to have such a useful tool available. I rather like the breadboard facility, allows you to see what is happening in real (or realish) time if you have a lot of long loops. > The reason gpsim halted is because address 0x90 is invalid for the > 16F877. The T1CON register (which I assume you're attempting to address) > is at address 0x10. So the problem is that your bank register is > incorrect; your pointing into bank 01 when you should be pointing into > bank 00. I don't know if the offending code was written by you or SDCC, > but in either case you may track down where the bank was (or was not) > getting written by using gpsim's trace command. For example, you can say > 'trace 100' to see what has happened for the last 100 instruction > cycles. This will allow you to inspect where things went awry. The offending assembly code was written by by sdcc from my C, the routine stops in a software serial port driver bit of code, from looking at the source browser (I know most pics nowadays have USARTS but I thought it would be better to have a software solution working first). However, this code has been fine earlier, it has been working on my pic16f877 development board for over a week when used with other routines. My assumption is that the use of more variables in other bits of code has caused sdcc to move one of the variables used by the serial routine into a place it should not have. Note I've been a bit lazy with my delay routine, basically estimating the delays by viewing the resultant RS232 signals on a scope. I should have produced the delay using in-line assembly so I knew exactly what the delays were! I've left all the comments just in-case I've made a boo-boo there! C: void Half_Bit_Delay(void) { unsigned char loop; //OK, PIC clocking at 20MHz // /4 = 5MHz // 200nsec per instruction // If we go for 19200 baud //52 instruction pause //assume loop takes 2, 26, but half bit, 13 // assume 4 instruction overhead //9 //Go for 9600 baud delay of 128 //With 128 1.5msec for 10 bits worth, start 8 stop //That gives a baud rate of 1.5 e -03 / 10 equates //to 6667 baud //Correct ! 128 * 6667 / 9600 = 89! //Which gives 8333 baud! //Tweek slihtly faster for (loop = 0; loop < 79 ; loop++ ) { } } Assembly produced by sdcc, gpsim freezes where marked: ;*** ; pBlock Stats: dbName = C ;*** ;entry: _Half_Bit_Delay ;Function start ; 2 exit points ;has an exit ;1 compiler assigned register : ; r0xB0 ;; Starting pCode block _Half_Bit_Delay ;Function start ; 2 exit points ; .line 103; "../plibpic/serial/serial-sw-2006-10-5.h" for (loop = 0; loop < 79 ; loop++ ) { MOVLW 0x4f BANKSEL r0xB0 MOVWF r0xB0 _00115_DS_ DECFSZ r0xB0,F GOTO _00115_DS_ <----- GPSIM seems to stop here! RETURN ; exit point of _Half_Bit_Delay All a bit odd though, as the routine works for a while before it bangs out. Also, I though sdcc insulated me from setting bank bits? Also a bit perplexed. Hmm, a lot of code playing around at 0x90 from elsewhere in my serial routine, a code snippet. Looks like it would be valid if the pic is working in banks 2 or 3 but from the error message I would assume it is in bank 0? I'm a bit confused by the 'BANKSEL' instruction, I assume it is some sort of assembler macro rather than a PIC instruction. ; .line 257; "../plibpic/serial/serial-sw-2006-10-5.h" serialbuff[serialbuff_index] = in; BANKSEL _serialbuff_index MOVF _serialbuff_index,W ADDLW (_serialbuff + 0) MOVWF r0x90 MOVLW high (_serialbuff + 0) BTFSC STATUS,0 ADDLW 0x01 MOVWF r0x91 MOVF r0x90,W MOVWF FSR BCF STATUS,7 BTFSC r0x91,0 BSF STATUS,7 MOVF r0x8F,W MOVWF INDF I need to RTFM a bit on trace, I seem either to get the last instruction or a lot of short lines of hex! Pete |
From: Raphael N. <rn...@we...> - 2006-10-09 08:34:15
|
Hi Peter, > Assembly produced by sdcc, gpsim freezes where marked: > > ;*** > ; pBlock Stats: dbName = C > ;*** > ;entry: _Half_Bit_Delay ;Function start > ; 2 exit points > ;has an exit > ;1 compiler assigned register : > ; r0xB0 > ;; Starting pCode block > _Half_Bit_Delay ;Function start > ; 2 exit points > ; .line 103; "../plibpic/serial/serial-sw-2006-10-5.h" > for (loop = 0; loop > < 79 ; loop++ ) { > MOVLW 0x4f > BANKSEL r0xB0 > MOVWF r0xB0 > _00115_DS_ > DECFSZ r0xB0,F > GOTO _00115_DS_ <----- GPSIM seems to stop here! > RETURN > ; exit point of _Half_Bit_Delay > > All a bit odd though, as the routine works for a while before > it bangs out. > Also, I though sdcc insulated me from setting bank bits? Also a bit > perplexed. The problem might be the newly introduced -r option, which is now passed on by SDCC to gplink to circumvent problems with devices with all memory locations being in shared banks; probably gplink now allocates r0xB0 to the (shared) location 0x90, which it should not... You might try to compile and link manually without -r to gplink. Also check if you ran out of memory (consult the .map file, gplink -m). HTH, Raphael Neider |
From: Peter C. <pe...@pe...> - 2006-10-11 18:10:17
|
On Monday 09 October 2006 09:34, Raphael Neider wrote: > The problem might be the newly introduced -r option, which is now passed > on by SDCC to gplink to circumvent problems with devices with all memory > locations being in shared banks; probably gplink now allocates r0xB0 to > the (shared) location 0x90, which it should not... You might try to > compile and link manually without -r to gplink. > Tried this, same problem occurs unfortunately, so I can't seem to see that as a workround. > Also check if you ran out of memory (consult the .map file, gplink -m). Hmm, I'm not really sure how to know, I'm not familiar with map files. I'm wondering if stuff (ie functions) are being linked in that are not being used, but then that could be my poor grasp of map files. Pete |
From: Raphael N. <rn...@we...> - 2006-10-13 11:49:11
|
Hi Pete, > > Also check if you ran out of memory (consult the .map file, gplink -m). > > Hmm, I'm not really sure how to know, I'm not familiar with map files. > I'm wondering if stuff (ie functions) are being linked in that are not > being used, but then that could be my poor grasp of map files. As this seems (to me) to be some kind of register allocation problem, I would require the complete code base to reproduce the bug. Alternatively (or as a preparation...), you might post/send me the generated .map/.lst files for inspection. (I wonder if the problem "moves" if you just move Half_Bit_Delay up or down in the file (exchange it with other functions) or change the order your project files are linked---the function you posted is itself not erroneous.) Regards, Raphael |
From: Peter C. <pe...@pe...> - 2006-10-14 12:50:01
|
On Friday 13 October 2006 12:48, Raphael Neider wrote: > As this seems (to me) to be some kind of register allocation problem, I > would require the complete code base to reproduce the bug. > Alternatively (or as a preparation...), you might post/send me the > generated .map/.lst files for inspection. > Code sent, check your mail! > (I wonder if the problem "moves" if you just move Half_Bit_Delay up or > down in the file (exchange it with other functions) or change the order > your project files are linked---the function you posted is itself not > erroneous.) I've moved the function to the end of the file that contains it and it makes no difference. Pete |
From: Raphael N. <rn...@we...> - 2006-10-15 01:06:13
|
Hi Pete, > > As this seems (to me) to be some kind of register allocation problem, I Actually, it was a BANKSEL problem in __uchar2fs, already reported in #1570934, and now (SDCC r4409) fixed. Please update your SDCC, recompile the library and get going ;-) Regards, Raphael Neider PS: Thanks again to "dev-hda" for pointing to the solution. |
From: Peter C. <pe...@pe...> - 2006-10-15 13:46:53
|
On Sunday 15 October 2006 02:05, Raphael Neider wrote: > Hi Pete, > > > > As this seems (to me) to be some kind of register allocation > > > problem, I > > Actually, it was a BANKSEL problem in __uchar2fs, already reported in > #1570934, and now (SDCC r4409) fixed. > Please update your SDCC, recompile the library and get going ;-) Now have: SDCC : mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08 2.6.1 #4409 (Oct 15 2006) (UNIX) I did a make uninstall on the old version and deleted /usr/local/share/sdcc to be safe before running make install on the updated version. Hmm, does not quite fix it. It removes the invalid register message, but both the real PIC and gpsim still get stuck after around 8 seconds of run time. According to gpsim this is still happening in my half_bit_delay routine. Puzzled. |
From: Raphael N. <rn...@we...> - 2006-10-15 13:51:17
|
Hi, > Now have: > > SDCC : mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08 > 2.6.1 #4409 (Oct 15 2006) (UNIX) > > I did a make uninstall on the old version and deleted /usr/local/share/sdcc > to be safe before running make install on the updated version. > > Hmm, does not quite fix it. It removes the invalid register message, but > both the real PIC and gpsim still get stuck after around 8 seconds of run > time. According to gpsim this is still happening in my half_bit_delay > routine. For me, gpsim just runs forever; does it stop with some kind of message at your site? Or does it simply loop forever and when you interrupt it, you happen to find it execute in half_bit_delay? > Puzzled. Agreed... Raphael |
From: Peter C. <pe...@pe...> - 2006-10-15 14:37:51
|
On Sunday 15 October 2006 14:50, Raphael Neider wrote: > For me, gpsim just runs forever; does it stop with some kind of message > at your site? Or does it simply loop forever and when you interrupt it, > you happen to find it execute in half_bit_delay? > It runs forever with no error message. However, it gets stuck. Changing from 100000 cycle/gui update to update every cycle (and remembering to click on 'run') shows that it is well and truly stuck. I am not happening by chance to find myself in half_bit_delay every time I stop it. The PIC itself appears to match this behaviour outwardly. I'm just wondering if I ought to rewrite my main program loop to see if it goes away as I cannot see any error. However, although it appears to get stuck around the time the program enters my main program loop I cannot understand why it choses to get stuck in 'Half_Bit_Delay'? Pete |
From: Peter C. <pe...@pe...> - 2006-10-16 19:47:33
|
On Sunday 15 October 2006 15:37, Peter Chant wrote: > I'm just wondering if I ought to rewrite my main program loop to see if > it goes away as I cannot see any error. However, although it appears to > get stuck around the time the program enters my main program loop I > cannot understand why it choses to get stuck in 'Half_Bit_Delay'? OK, I saved the original file and hacked it about to see what happened. Removing the floating point maths caused the problem (as demonstrated in gpsim) to go away. Reintroducing floating point maths brought it back. Not sure why it gets stuck in 'half_bit_delay' as that has nothing to do with floating point. I can re-write without floating point maths but it is a bit of a shame as it brought in several convieniences. Pete |