On 6/8/08, Raphael Neider <[EMAIL PROTECTED]> 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 > Sdcc-user@lists.sourceforge.net > 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 ------------------------------------------------------------------------- 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
