From: Get S. <ds...@gm...> - 2008-06-05 13:55:05
|
I tried to simulate (PICSim IDE, Oshonsoft) the hex file, but I got "Hardware stack overflow" #include "pic16f84.h" void main() { TRISB = 0; for (;;) { PORTB = 0; PORTB = 1; } } ".... \sdcc\bin\sdcc.exe" --vc -mpic14 -p16f84 blinkled.c Thanks |
From: Raphael N. <rn...@we...> - 2008-06-06 14:36:40
|
Get Started wrote: > I tried to simulate (PICSim IDE, Oshonsoft) the hex file, but I got > "Hardware stack overflow" There was a similar report recently stating the same problem. Can you track it down more precisely? Can you single-step through the program to identify the causing instruction? I do not have the software, so I cannot try myself. Alternatively you can try to replace the startup code by defining a function as follows: void _sdcc_gsinit_startup (void) { __asm pagesel _main goto _main __endasm; } WARNING: This will leave all global and/or static variables undefined, even if they are initialized in C! I suspect a simulator bug on reading from flash: The initialization code (like normal code as well) reads from code memory by calling a code fragment that sets the PCLATH and PCL registers to the address to be read, executing the the RETLW <val> instruction there and thus returning to the caller of the code fragment. Maybe the simulator also partly executes the following instruction, which is likely to be a RETLW <val2> instruction as well, popping another return value from the stack?!? For the record: gpsim happily simulates the code. > #include "pic16f84.h" > > void main() > { > TRISB = 0; > > for (;;) > { > PORTB = 0; > PORTB = 1; > } > } Hope that helps, Raphael |
From: Get S. <ds...@gm...> - 2008-06-06 15:47:09
|
Instructions counter: 94 Clock cycles counter: 484 Last instruction: call 0xAC You may install the software mentioned below, if you have windows. I tried it in an other simulator, with the similar problem. Thanks On Fri, Jun 6, 2008 at 4:36 PM, Raphael Neider <rn...@we...> wrote: > > > Get Started wrote: > > I tried to simulate (PICSim IDE, Oshonsoft) the hex file, but I got > > "Hardware stack overflow" > > There was a similar report recently stating the same problem. Can you > track it down more precisely? Can you single-step through the program to > identify the causing instruction? I do not have the software, so I > cannot try myself. > > > > Alternatively you can try to replace the startup code by defining a > function as follows: > > void _sdcc_gsinit_startup (void) { > __asm > pagesel _main > goto _main > __endasm; > } > > WARNING: This will leave all global and/or static variables undefined, > even if they are initialized in C! > > I suspect a simulator bug on reading from flash: The initialization code > (like normal code as well) reads from code memory by calling a code > fragment that sets the PCLATH and PCL registers to the address to be > read, executing the the RETLW <val> instruction there and thus returning > to the caller of the code fragment. Maybe the simulator also partly > executes the following instruction, which is likely to be a RETLW <val2> > instruction as well, popping another return value from the stack?!? > > For the record: gpsim happily simulates the code. > > > #include "pic16f84.h" > > > > void main() > > { > > TRISB = 0; > > > > for (;;) > > { > > PORTB = 0; > > PORTB = 1; > > } > > } > > Hope that helps, > Raphael > > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > |
From: Raphael N. <rn...@we...> - 2008-06-07 22:04:56
|
> Instructions counter: 94 > Clock cycles counter: 484 > Last instruction: call 0xAC OK, I reproduced the error using oshonsoft's PIC simulator. I solved it by selecting the correct PIC (16f84) rather than using the simulator's default (16f877), which messes up the software (pseudo) stack: the software stack is placed by the linker into an address range that is plain memory on the 16f84, but occupied by SFRs on the 16f877. As a result, reading from code memory (during initialization) does not jump to the RETLW instructions, but always to address 0 (the fixed? contents of the SFRs), the RESET vector. This causes an infinite loop, occupying two HW-stack slots in each iteration (CALL __gptrget2 and a nested CALL __codeptrget1). So, no bug here after all. Regards, Raphael |
From: Get S. <ds...@gm...> - 2008-06-09 11:41:41
|
On 6/8/08, Raphael Neider <rn...@we...> wrote: > >> Instructions counter: 94 >> Clock cycles counter: 484 >> Last instruction: call 0xAC > > OK, I reproduced the error using oshonsoft's PIC simulator. I solved it > by selecting the correct PIC (16f84) rather than using the simulator's > default (16f877), which messes up the software (pseudo) stack: the > software stack is placed by the linker into an address range that is > plain memory on the 16f84, but occupied by SFRs on the 16f877. As a > result, reading from code memory (during initialization) does not jump > to the RETLW instructions, but always to address 0 (the fixed? contents > of the SFRs), the RESET vector. This causes an infinite loop, occupying > two HW-stack slots in each iteration (CALL __gptrget2 and a nested CALL > __codeptrget1). > > So, no bug here after all. > > Regards, > Raphael > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > It means, it is fixed in the source code? I have to download the latest snapshot? Thanks |
From: Raphael N. <rn...@we...> - 2008-06-09 11:57:24
|
>> OK, I reproduced the error using oshonsoft's PIC simulator. I solved it >> by selecting the correct PIC (16f84) rather than using the simulator's >> default (16f877), which messes up the software (pseudo) stack: the > > It means, it is fixed in the source code? I have to download the > latest snapshot? No, it is not fixed, you do not need to download anything. Just start the PIC simulator IDE, load the .hex file, SELECT THE CORRECT PROCESSOR (click on the name "16f877" somewhere on the top, left hand side, to get a list of possible devices, select the 16f84), and start the simulation. You MUST select the device you compiled for (16f84). HTH, Raphael |
From: Get S. <ds...@gm...> - 2008-06-09 13:02:44
|
I tested it with p16f84 in PIC Simulator IDE previously... On 6/9/08, Raphael Neider <rn...@we...> wrote: > >>> OK, I reproduced the error using oshonsoft's PIC simulator. I solved it >>> by selecting the correct PIC (16f84) rather than using the simulator's >>> default (16f877), which messes up the software (pseudo) stack: the >> >> It means, it is fixed in the source code? I have to download the >> latest snapshot? > > No, it is not fixed, you do not need to download anything. Just start > the PIC simulator IDE, load the .hex file, SELECT THE CORRECT PROCESSOR > (click on the name "16f877" somewhere on the top, left hand side, to get > a list of possible devices, select the 16f84), and start the simulation. > You MUST select the device you compiled for (16f84). > > HTH, > Raphael > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > |