From: V. B. <vba...@go...> - 2012-06-11 14:08:07
|
Hi, I am trying to use sdcc (pic14) with a pic16f876a. The compilation works but the program does not. Here is the source, test.c: ################# #define __16f876a #include "pic14/pic16f876a.h" // Setup chip configuration __code unsigned short __at(0x2007) _conf = (_CP_OFF & _WDT_OFF & _BODEN_OFF & _PWRTE_ON & _HS_OSC & _LVP_OFF); void main(void) { TRISB = 0x00; // PORT B all output PORTB = 0xFF; // Enable all while(1) { } } ################# These are the commands I use to compile: /opt/cross/bin/sdcc -c -mpic14 -p16f876a -I /opt/cross/share/sdcc/non-free/include/ --use-non-free test.c gpasm -c test.asm gplink test.o /opt/cross/share/sdcc/non-free/lib/pic14/pic16f876a.lib /opt/cross/share/sdcc/lib/pic14/libsdcc.lib -I/opt/cross/share/sdcc/include/ -a inhx8m -O 1 -o test.hex Hardware: Just two LEDs at RB2 and RB3 (which stay off). > sdcc --version SDCC : mcs51/gbz80/z80/z180/r2k/r3ka/ds390/pic16/pic14/TININative/ds400/hc08/s08 3.1.5 #7873 (Jun 10 2012) (Linux) I use a bootloader, but the program also does not work when flashed directly. Changing STARTUP code 0x0000 nop pagesel __sdcc_gsinit_startup goto __sdcc_gsinit_startup to STARTUP code 0x0000 nop pagesel _main goto _main in test.asm gives a working program (the leds are on). Another asm program compiled with gputils also works. What may be the problem here? Kind Regards, Vinzenz |
From: Don W. <do...@sn...> - 2012-06-11 20:14:02
|
The pic14 bugs are a bit backed up. See bug ID 3521376 for more info on _sdcc_gsinit_startup. http://sourceforge.net/tracker/?func=detail&aid=3521376&group_id=599&atid=100599 If the pointers there are bad, probably other pointers are also not working. - Don On Jun 11, V. Bargsten propounded certain bytes, to wit: > Subject: [Sdcc-user] pic14 problem: program does not work with _sdcc_gsini > > Hi, > > I am trying to use sdcc (pic14) with a pic16f876a. The compilation works > but the program does not. > > Here is the source, test.c: > ################# > #define __16f876a > #include "pic14/pic16f876a.h" > > // Setup chip configuration > __code unsigned short __at(0x2007) _conf = (_CP_OFF & > _WDT_OFF & > _BODEN_OFF & > _PWRTE_ON & > _HS_OSC & > _LVP_OFF); > > void main(void) > { > TRISB = 0x00; // PORT B all output > PORTB = 0xFF; // Enable all > while(1) { > } > } > ################# > > These are the commands I use to compile: > /opt/cross/bin/sdcc -c -mpic14 -p16f876a -I > /opt/cross/share/sdcc/non-free/include/ --use-non-free test.c > gpasm -c test.asm > gplink test.o /opt/cross/share/sdcc/non-free/lib/pic14/pic16f876a.lib > /opt/cross/share/sdcc/lib/pic14/libsdcc.lib > -I/opt/cross/share/sdcc/include/ -a inhx8m -O 1 -o test.hex > > Hardware: Just two LEDs at RB2 and RB3 (which stay off). > > > sdcc --version > SDCC : > mcs51/gbz80/z80/z180/r2k/r3ka/ds390/pic16/pic14/TININative/ds400/hc08/s08 3.1.5 > #7873 (Jun 10 2012) (Linux) > > I use a bootloader, but the program also does not work when flashed > directly. > > Changing > STARTUP code 0x0000 > nop > pagesel __sdcc_gsinit_startup > goto __sdcc_gsinit_startup > > to > > STARTUP code 0x0000 > nop > pagesel _main > goto _main > > in test.asm gives a working program (the leds are on). Another asm > program compiled with gputils also works. > What may be the problem here? > > Kind Regards, > Vinzenz > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user >-- End of excerpt from V. Bargsten' |
From: Gál Z. <tra...@fr...> - 2012-06-22 15:56:23
|
Hello, I realised that my programs doesn't work if I don't use a simple routine to avoid linking the sdcc_gsinit_startup code. It could be problematic for those sdcc users who started to use sdcc for a couple months ago. I am using this simple code for my programs, because the generated code is smaller: void _sdcc_gsinit_startup(void) { __asm pagesel _main __endasm; __asm goto _main __endasm; } It was offered in the mail-list somewhere. Unfortunately I run into this problem time to time, when I start a new project. My first step is driving a LED, which is very simple if everything is working. My brain is very small, so I am alway forgetting to add this simple routine to the program, and the LED isn't working as I expected. I am downloading the source of SDCC from svn every time and do the compiling myself. I was thinking that I am doing something with it, and that is why gsinit doesn't working. Today I downloaded and installed the SDCC 3.2.0 rc1, but the situation is the same. So my program doesn't work if I don't avoid to linking the gsint routine from the library. If I will have more time I will check where the program strugle. I hope on this weekend I will have time for it. Zsolt |
From: Borut R. <bor...@gm...> - 2012-06-22 16:15:22
|
On Fri, Jun 22, 2012 at 5:56 PM, Gál Zsolt <tra...@fr...> wrote: > Hello, > > I realised that my programs doesn't work if I don't use a simple > routine to avoid linking the sdcc_gsinit_startup code. It could be > problematic for those sdcc users who started to use sdcc for a couple > months ago. I am using this simple code for my programs, because the > generated code is smaller: > > void _sdcc_gsinit_startup(void) > { > __asm pagesel _main __endasm; > __asm goto _main __endasm; > } > > It was offered in the mail-list somewhere. Unfortunately I run into > this problem time to time, when I start a new project. My first step > is driving a LED, which is very simple if everything is working. My > brain is very small, so I am alway forgetting to add this simple > routine to the program, and the LED isn't working as I expected. > > I am downloading the source of SDCC from svn every time and do the > compiling myself. I was thinking that I am doing something with it, > and that is why gsinit doesn't working. Today I downloaded and > installed the SDCC 3.2.0 rc1, but the situation is the same. So my > program doesn't work if I don't avoid to linking the gsint routine > from the library. > > If I will have more time I will check where the program strugle. I > hope on this weekend I will have time for it. Any help is welcome! If it is really caused by bug ID 3521376 at http://sourceforge.net/tracker/?func=detail&aid=3521376&group_id=599&atid=100599 it would be fine if somebody check in which svn revision the bug appeared and which change in sdcc source code caused it. The information in the bug report seems inaccurete to me: no pic14 related changes were made in svn revision #7080. Borut |
From: Gál Z. <tra...@fr...> - 2012-06-22 21:15:45
|
I think the problem is here: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3521376&group_id=599 Don Wooton was writing about when appeared it. I found the same result, when I started to examine the code. _cinit is an address in code memory, but the compiled code looks like it handle like a general purpose register. The BANKSEL macro is used to select a register bank. But _cinit is not a register in a bank. MOVLW 0x02 BANKSEL _cinit ADDWF (_cinit + 0),W BANKSEL r0x1002 MOVWF r0x1002 CLRF r0x1003 RLF r0x1003,F BANKSEL _cinit MOVF (_cinit + 1),W BANKSEL r0x1003 ADDWF r0x1003,F 2012/6/22 Borut Ražem <bor...@gm...>: > On Fri, Jun 22, 2012 at 5:56 PM, Gál Zsolt <tra...@fr...> wrote: >> >> Hello, >> >> I realised that my programs doesn't work if I don't use a simple >> routine to avoid linking the sdcc_gsinit_startup code. It could be >> problematic for those sdcc users who started to use sdcc for a couple >> months ago. I am using this simple code for my programs, because the >> generated code is smaller: >> >> void _sdcc_gsinit_startup(void) >> { >> __asm pagesel _main __endasm; >> __asm goto _main __endasm; >> } >> >> It was offered in the mail-list somewhere. Unfortunately I run into >> this problem time to time, when I start a new project. My first step >> is driving a LED, which is very simple if everything is working. My >> brain is very small, so I am alway forgetting to add this simple >> routine to the program, and the LED isn't working as I expected. >> >> I am downloading the source of SDCC from svn every time and do the >> compiling myself. I was thinking that I am doing something with it, >> and that is why gsinit doesn't working. Today I downloaded and >> installed the SDCC 3.2.0 rc1, but the situation is the same. So my >> program doesn't work if I don't avoid to linking the gsint routine >> from the library. >> >> If I will have more time I will check where the program strugle. I >> hope on this weekend I will have time for it. > > > Any help is welcome! > > If it is really caused by bug ID 3521376 > at http://sourceforge.net/tracker/?func=detail&aid=3521376&group_id=599&atid=100599 it > would be fine if somebody check in which svn revision the bug appeared and > which change in sdcc source code caused it. The information in the bug > report seems inaccurete to me: no pic14 related changes were made in svn > revision #7080. > > Borut > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > -- ~~~~~~~~~~~~~~~~ http://galzsolt.zzl.org |
From: Gál Z. <tra...@fr...> - 2012-06-22 22:57:46
|
Here is a copy from idata.c: 70 unsigned num, size; 71 __code cinit_t *cptr; 72 __code char *src; 73 __data char *dst; I think *cptr is not takes place in code memory rather in data memory. So the __code modifier shouldn't be in line 71. I tried it, and it is working for me. The generated code is more beautiful: ; .line 76; "../idata.c" cptr = &cinit.entry[0]; MOVLW high (_cinit + 2) MOVWF r0x1002 MOVLW (_cinit + 2) MOVWF r0x1003 MOVLW 0x80 MOVWF r0x1004 |
From: Borut R. <bor...@gm...> - 2012-06-23 10:03:20
|
I have an impression that __code acts oposite as intendend: if __code is defined, then _cinit is assumed to be in data memory - see the generated asm with BANKSELs, which is wrong. Omitting "__code" in line 71 is just a (ugly) workaround since "__code cinit_t *cptr" seems to be correct: cptr IS a pointer to cinit_t structure in code section. Has anybody investigated in which svn revision the bug appeared? If it was really in rev. 7080, then it is an ugly side effect of optralloc branch merge :-( I think this should be fixed ASAP, before the RC2 release, so any help is welcome. Raphael, can you please take a look to this problem? Borut On Sat, Jun 23, 2012 at 12:57 AM, Gál Zsolt <tra...@fr...>wrote: > Here is a copy from idata.c: > > 70 unsigned num, size; > 71 __code cinit_t *cptr; > 72 __code char *src; > 73 __data char *dst; > > I think *cptr is not takes place in code memory rather in data memory. > So the __code modifier shouldn't be in line 71. I tried it, and it is > working for me. The generated code is more beautiful: > > ; .line 76; "../idata.c" cptr = &cinit.entry[0]; > MOVLW high (_cinit + 2) > MOVWF r0x1002 > MOVLW (_cinit + 2) > MOVWF r0x1003 > MOVLW 0x80 > MOVWF r0x1004 |
From: Gál Z. <tra...@fr...> - 2012-06-23 10:25:15
|
Examing the macros.inc file in sdcc/device/lib/pic14/libsdcc/regular, it can help to answer the question: ; ----------------------------------------------- ; --- generic pointer access helpers ; ----------------------------------------------- GPTRTAG_DATA EQU 0x00 GPTRTAG_CODE EQU 0x80 ; dispatch according to gptr type select_routine macro dataptr, codeptr ; __data pointer tag: 0x00 xorlw GPTRTAG_DATA btfsc _STATUS, Z goto dataptr ; __code pointer tag: 0x80 xorlw (GPTRTAG_DATA ^ GPTRTAG_CODE) btfsc _STATUS, Z goto codeptr endm I think pointers are 24 bit variables in the data memory ( register banks ) and according the highest bit ( 23 ) will decide this pointer is pointed a code memory location or a register file position. That is why I think that the __code modifier should be removed. If I give this modifier to a variable it means that the variable will be in program memory. But program memory isn't changeable. 2012/6/23 Borut Ražem <bor...@gm...>: > I have an impression that __code acts oposite as intendend: if __code is > defined, then _cinit is assumed to be in data memory - see the generated asm > with BANKSELs, which is wrong. > > Omitting "__code" in line 71 is just a (ugly) workaround since "__code > cinit_t *cptr" seems to be correct: cptr IS a pointer to cinit_t structure > in code section. > > Has anybody investigated in which svn revision the bug appeared? If it was > really in rev. 7080, then it is an ugly side effect of optralloc branch > merge :-( > > I think this should be fixed ASAP, before the RC2 release, so any help is > welcome. Raphael, can you please take a look to this problem? > > Borut > > > On Sat, Jun 23, 2012 at 12:57 AM, Gál Zsolt <tra...@fr...> > wrote: >> >> Here is a copy from idata.c: >> >> 70 unsigned num, size; >> 71 __code cinit_t *cptr; >> 72 __code char *src; >> 73 __data char *dst; >> >> I think *cptr is not takes place in code memory rather in data memory. >> So the __code modifier shouldn't be in line 71. I tried it, and it is >> working for me. The generated code is more beautiful: >> >> ; .line 76; "../idata.c" cptr = &cinit.entry[0]; >> MOVLW high (_cinit + 2) >> MOVWF r0x1002 >> MOVLW (_cinit + 2) >> MOVWF r0x1003 >> MOVLW 0x80 >> MOVWF r0x1004 > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > -- ~~~~~~~~~~~~~~~~ http://galzsolt.zzl.org |
From: Borut R. <bor...@gm...> - 2012-06-23 12:01:07
|
On Sat, Jun 23, 2012 at 12:25 PM, Gál Zsolt <tra...@fr...>wrote: > Examing the macros.inc file in sdcc/device/lib/pic14/libsdcc/regular, > it can help to answer the question: > > ; ----------------------------------------------- > ; --- generic pointer access helpers > ; ----------------------------------------------- > > GPTRTAG_DATA EQU 0x00 > GPTRTAG_CODE EQU 0x80 > > ; dispatch according to gptr type > select_routine macro dataptr, codeptr > ; __data pointer tag: 0x00 > xorlw GPTRTAG_DATA > btfsc _STATUS, Z > goto dataptr > ; __code pointer tag: 0x80 > xorlw (GPTRTAG_DATA ^ GPTRTAG_CODE) > btfsc _STATUS, Z > goto codeptr > endm > > I think pointers are 24 bit variables in the data memory ( register > banks ) and according the highest bit ( 23 ) will decide this pointer > is pointed a code memory location or a register file position. Right. > That is > why I think that the __code modifier should be removed. If I give this > modifier to a variable it means that the variable will be in program > memory. But program memory isn't changeable. > The cinit_t structure members are read from the program memory, they are never written. I still think that __code qualifier is ok. Borut > 2012/6/23 Borut Ražem <bor...@gm...>: > > I have an impression that __code acts oposite as intendend: if __code is > > defined, then _cinit is assumed to be in data memory - see the generated > asm > > with BANKSELs, which is wrong. > > > > Omitting "__code" in line 71 is just a (ugly) workaround since "__code > > cinit_t *cptr" seems to be correct: cptr IS a pointer to cinit_t > structure > > in code section. > > > > Has anybody investigated in which svn revision the bug appeared? If it > was > > really in rev. 7080, then it is an ugly side effect of optralloc branch > > merge :-( > > > > I think this should be fixed ASAP, before the RC2 release, so any help is > > welcome. Raphael, can you please take a look to this problem? > > > > Borut > > > > > > On Sat, Jun 23, 2012 at 12:57 AM, Gál Zsolt <tra...@fr...> > > wrote: > >> > >> Here is a copy from idata.c: > >> > >> 70 unsigned num, size; > >> 71 __code cinit_t *cptr; > >> 72 __code char *src; > >> 73 __data char *dst; > >> > >> I think *cptr is not takes place in code memory rather in data memory. > >> So the __code modifier shouldn't be in line 71. I tried it, and it is > >> working for me. The generated code is more beautiful: > >> > >> ; .line 76; "../idata.c" cptr = &cinit.entry[0]; > >> MOVLW high (_cinit + 2) > >> MOVWF r0x1002 > >> MOVLW (_cinit + 2) > >> MOVWF r0x1003 > >> MOVLW 0x80 > >> MOVWF r0x1004 > |
From: Raphael N. <rn...@we...> - 2012-06-23 13:26:14
Attachments:
cinit-fix.patch
|
Hi, > The cinit_t structure members are read from the program memory, they are > never written. I still think that __code qualifier is ok. Yep, we just need the symbol to find the cinit-structure in ROM. >>> Has anybody investigated in which svn revision the bug appeared? If it >>> was really in rev. 7080, then it is an ugly side effect of optralloc >>> branch merge :-( Nope, I did not (yet) search for the first bad revision. >>> I think this should be fixed ASAP, before the RC2 release, so any help >>> is welcome. Raphael, can you please take a look to this problem? Done. Please find a patch against r7955 attached. >>>> ; .line 76; "../idata.c" cptr = &cinit.entry[0]; >>>> MOVLW high (_cinit + 2) >>>> MOVWF r0x1002 >>>> MOVLW (_cinit + 2) >>>> MOVWF r0x1003 >>>> MOVLW 0x80 >>>> MOVWF r0x1004 Similar code is generated once the above patch is applied. The code gerenator is/was confusing address calculations and data manipulations: Do we want to read the byte at _cinit and add 2 to the value found there *xor* do we want to read the byte at address (_cinit + 2)? If anyone with a sufficiently large PIC14 program could confirm that this (a) actually does fix the problem and (b) does not break other stuff, that would be great. I can confirm that the fix is executed only twice in the PIC14 library code: only in libsdcc/{regular,enhanced}/idata.c. But due to the limited code base, this does not tell us too much. You can compile your projects with --debug-xtra to see messages like idata.c:76: CHECK: using address of '_cinit' instead of contents whenever the fix is used during code generation. Raphael |
From: Borut R. <bor...@gm...> - 2012-06-23 13:47:13
|
Raphael, thanks, I knew who I have to ask for help ;-) There were many changes since the RC1 release, so I plan to make the RC2 release earlier: 2012-06-24 and make the RC3 at the date RC2 was originally planned: 2012-07-01. I will apply Raphael's patch immediately since the currently generated code is wrong and it can't be worse with the patch applied. If nobody finds a mistake in the patch, then the RC2 will be made from tomorrow's snapshot builds, if not we will have to decide how to proceed (probably delay the new RC2 date I proposed by few days). In the mean time: pic14 users please do test! Borut On Sat, Jun 23, 2012 at 3:10 PM, Raphael Neider <rn...@we...> wrote: > Hi, > > > The cinit_t structure members are read from the program memory, they are >> never written. I still think that __code qualifier is ok. >> > > Yep, we just need the symbol to find the cinit-structure in ROM. > > > Has anybody investigated in which svn revision the bug appeared? If it >>>> was really in rev. 7080, then it is an ugly side effect of optralloc >>>> branch merge :-( >>>> >>> > Nope, I did not (yet) search for the first bad revision. > > > I think this should be fixed ASAP, before the RC2 release, so any help is >>>> welcome. Raphael, can you please take a look to this problem? >>>> >>> > Done. Please find a patch against r7955 attached. > > > ; .line 76; "../idata.c" cptr = &cinit.entry[0]; >>>>> MOVLW high (_cinit + 2) >>>>> MOVWF r0x1002 >>>>> MOVLW (_cinit + 2) >>>>> MOVWF r0x1003 >>>>> MOVLW 0x80 >>>>> MOVWF r0x1004 >>>>> >>>> > Similar code is generated once the above patch is applied. > The code gerenator is/was confusing address calculations and data > manipulations: Do we want to read the byte at _cinit and add 2 to the value > found there *xor* do we want to read the byte at address (_cinit + 2)? > > If anyone with a sufficiently large PIC14 program could confirm that this > (a) actually does fix the problem and (b) does not break other stuff, that > would be great. > I can confirm that the fix is executed only twice in the PIC14 library > code: only in libsdcc/{regular,enhanced}/**idata.c. But due to the > limited code base, this does not tell us too much. > You can compile your projects with --debug-xtra to see messages like > > idata.c:76: CHECK: using address of '_cinit' instead of contents > > whenever the fix is used during code generation. > > Raphael |
From: V. B. <vba...@go...> - 2012-06-23 15:21:56
|
Am 23.06.2012 15:47, schrieb Borut Raz(em: > Raphael, > > thanks, I knew who I have to ask for help ;-) > > There were many changes since the RC1 release, so I plan to make the > RC2 release earlier: 2012-06-24 and make the RC3 at the date RC2 was > originally planned: 2012-07-01. > > I will apply Raphael's patch immediately since the currently generated > code is wrong and it can't be worse with the patch applied. If nobody > finds a mistake in the patch, then the RC2 will be made from > tomorrow's snapshot builds, if not we will have to decide how to > proceed (probably delay the new RC2 date I proposed by few days). > > In the mean time: pic14 users please do test! Works in my case. Thank you all very much. Regards, Vinzenz > > Borut > > On Sat, Jun 23, 2012 at 3:10 PM, Raphael Neider <rn...@we... > <mailto:rn...@we...>> wrote: > > Hi, > > > The cinit_t structure members are read from the program > memory, they are > never written. I still think that __code qualifier is ok. > > > Yep, we just need the symbol to find the cinit-structure in ROM. > > > Has anybody investigated in which svn revision the bug > appeared? If it > was really in rev. 7080, then it is an ugly side > effect of optralloc > branch merge :-( > > > Nope, I did not (yet) search for the first bad revision. > > > I think this should be fixed ASAP, before the RC2 > release, so any help is welcome. Raphael, can you > please take a look to this problem? > > > Done. Please find a patch against r7955 attached. > > > ; .line 76; "../idata.c" cptr = > &cinit.entry[0]; > MOVLW high (_cinit + 2) > MOVWF r0x1002 > MOVLW (_cinit + 2) > MOVWF r0x1003 > MOVLW 0x80 > MOVWF r0x1004 > > > Similar code is generated once the above patch is applied. > The code gerenator is/was confusing address calculations and data > manipulations: Do we want to read the byte at _cinit and add 2 to > the value found there *xor* do we want to read the byte at address > (_cinit + 2)? > > If anyone with a sufficiently large PIC14 program could confirm > that this (a) actually does fix the problem and (b) does not break > other stuff, that would be great. > I can confirm that the fix is executed only twice in the PIC14 > library code: only in libsdcc/{regular,enhanced}/idata.c. But due > to the limited code base, this does not tell us too much. > You can compile your projects with --debug-xtra to see messages like > > idata.c:76: CHECK: using address of '_cinit' instead of contents > > whenever the fix is used during code generation. > > Raphael > > |
From: Gál Z. <tra...@fr...> - 2012-06-24 06:36:59
|
The test with normal and enhanced core PIC was done successfully. SDCC is working well for me again. Thanks for the effort. Zsolt $ sdcc -v SDCC : pic14 3.2.0 #7959 (Jun 23 2012) (Linux) $ gpasm -v gpasm-0.14.2 #711 (Jun 23 2012) $ uname -mrsv Linux 3.2.0-0.bpo.2-686-pae #1 SMP Sun Jun 3 22:21:19 UTC 2012 i686 $ cat /etc/issue Debian GNU/Linux 6.0 |