gnupic: Re: [gnupic] gpsim stepping bug
Subject:
Re: [gnupic] gpsim stepping bug
From:
"Scott Dattalo" ####@####.####
Date:
22 Aug 2005 04:04:18 +0100
Message-Id: <61460.67.113.28.45.1124679849.squirrel@67.113.28.45>
On Mon, 2005-08-22 at 10:03 +1200, David McNab wrote:
> Hi,
>
> I've been using various versions of gpsim for testing/debugging code for
> pic18f452.
>
> Currently I'm using the CVS vers of gpsim.
>
> With every version I've tried, the 'step' command ('s' in source or
> progmem window, or 'step' command from console) works fine.
>
> But the 'step over' command ('o' in src or progmem window, or 'step
> over' in console) doesn't work. Effect of this latter command, when the
> PC is at a CALL, is to actually enter the routine, show the first line,
> then go into free running, ignoring breakpoints, with the console
> repeatedly showing "'sleep' not implemented".
This is a bug.
The problem is that the 'over' command sets a break at the instruction
immediately following the current one. gpsim is a assuming that
instructions are only one word long. However, the CALL instruction is a
two-word opcode and so the step-over command sets a break on the second
word of CALL - and this never gets hit.
As a work around, you can try changing the CALL's to RCALL's or you can
manually try setting a break at the following instruction.
> This bug is very painful, since I can't step over lengthy routines
> without manually setting a breakpoint after the call.
>
> Also, setting breakpoints in the source asm window doesn't work either.
> The breakpoint is displayed, but it doesn't trip.
?. This one works for me. How recent is your copy from CVS? I fixed a bug
about 3 or 4 weeks ago for the p18Fxxx family that was affected by this.
> One last bug - even though I've got the .cod file properly loaded, gpsim
> is not accepting the console command 'break e foo', where 'foo' is an
> address label in the program. I noticed that gpsim 0.21.4 allowed this -
> I'd downgrade to 0.21.4, except it has a dealbreaker bug of its own -
> whenever I have the RAM window open, the source window doesn't update
> with program execution.
The 'break e foo' bug may be related to the fix I made several weeks ago
too. The problem was that a recent change regarding indexing into program
memory broke the 18F family. The break was getting set, but at the wrong
address!
Or if you're building using object files, then 'foo' has to be made GLOBAL.
> Scott - Any prognosis and/or time estimate on these?
I think the break point thing is fixed. The step over is not. Let me look
into this. At the moment I've got a fairly significant chunk of code to
check in. Most of it is for the regression tests. I've also begun updating
the USART module finally.
> Lastly - sorry for coming across as a whiner - gpsim is great and has
> saved my bacon on numerous occasions. It's an indispensable part of my
> development cycle now. If you've got time, it'd be nice to see those
> wrinkles get ironed out.
I've got three kids ages 2, 7 and 10, so my whining threshold is pretty high!
Scott
