gnupic: gpsim 18F* problems
Subject:
gpsim 18F* problems
From:
Ian Jackson ####@####.####
Date:
10 Jan 2005 16:16:55 +0000
Message-Id: <16866.43635.377188.609705@davenant.relativity.greenend.org.uk>
I recently used gpsim to try to find a fault in a piece of pic
firmware we're developing. I thought I would pass on some feedback
from my experience. I'm sorry that this doesn't come with a patch but
I found the class hierarchy and processor version support mechanisms
very hard to follow, so that I wasn't able to develop a patch I would
have confidence in.
The program was for an 18F458, but I believe this is close enough to
the allegedly sort-of supported 18F442; the 18F442 simulator was by
and large able to simulate the aspects of the program that were
relevant, at least so far as to help find the difficult bug I was
hunting. References below to correct behaviour of gpsim, or to actual
behaviour of the pic, are based on the data sheet covering the
PIC18F458; I don't have the relevant data sheet for the 18F442 to hand
and am not familiar with it, but I saw no evidence that the features I
was trying at this stage to simulate differ significantly.
1. Peripheral interrupts (at least, UART receive interrupts) are not
handled properly. The code which deals with generating them
doesn't know about the PIC18 series's two interrupt priority
levels, and so doesn't call set_interrupt_vector when setting the
interrupt. The result is that when the interrupt occurs, the
processor vectors to 0 (this value happens, in my situation, to be
what is left in the interrupt vector variable) instead of the
correct location.
The machinery here seemed confusing and not easy to fix. I
couldn't find any implementation of the IPRs (interrupt priority
registers) so I imagine that this bug exists with many of the other
peripherals too. It wasn't clear how to add support for the IPRs
in a sane and orthogonal way.
I was able to simulate my program by making peripheral_interrupt a
virtual method and adding an INTCON_16::peripheral_interrupt
implementation which, as a kludge, always calls
set_interrupt_vector(INTERRUPT_VECTOR_LO) before set_interrupt().
2. TMR0 is not enabled at startup. Although T0CON::T0CON sets
por_value = 0xff, after the simulated processor is reset the `x'
CLI command shows T0CON set to 0. I was not able to see why this
wasn't working, but I was able to simulate my program by adding an
explicit initialisation of T0CON to the actual pic code.
3. Program addresses shown by gpsim are halved, compared to canonical
addresses as used and shown by gpasm, etc. Ie, the addresses shown
by gpsim count 1 for each program word, but for the 16-bit devices,
the program memory addresses are conventionally byte addresses
(so the pic's pc must always be even in this notation).
4. The device configuration area is not supported (in my case,
I get a warning about an unhandled extended linear address while
loading the .hex file). This means that the WDT will not be
disabled (as it should be in my application), and various other
configuration aspects may be wrong.
5. I would have liked to improve gpsim by adding better support
for the PIC type I'm actually using, but I found the internal code
structure too tangled and the documentation too sparse.
I'm sorry to report that after having struggled with gpsim, and
grepped and read the source code looking for the above bugs, that
gpsim will be close to a last resort debugging technique for me. For
it to be good enough for routine use it would be necessary for gpsim
to be sufficiently correct (and internally disentangled) that using it
doesn't involve debugging gpsim at the same time as trying to debug
the pic program under test - and in some cases fighting bugs in gdb's
C++ and shared library support too !
Thanks,
Ian.
