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
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
