gnupic: Trouble with gpsim, WDT, and TMR1H
Subject:
Re: Trouble with gpsim, WDT, and TMR1H
From:
estyler ####@####.####
Date:
29 Nov 2004 10:52:18 +0000
Message-Id: <41AAFF88.7080500@plotinka.ru>
Hi Jeff,
Jeff Jackowski wrote:
>I've been working on an odd project for a while, and now I can't add a
>feature because I can't seem to get the timer 1 interrupt to work. So I
>decided to try out gpsim but there are two problems preventing me from
>using it. I installed gpsim from the rpms on the gpsim web site.
>
>First of all, when gpsim starts it enables the WDT. The program I've
>written does not use the WDT. I know the config word in the hex file is
>set to disable the WDT. If that wasn't the case, it wouldn't run properly
>on my test hardware. As gpsim runs the program, it does simulate rests
>caused by the WDT. As a temporary, partial fix, I tell gpsim to simulate a
>2.1GHz pic.
>
>
>
Really, gpsim enables WDT by default. But your programmers may disable
it by default. I had such a problem too. Here's a solution:
__CONFIG _HS_OSC & _WDT_OFF & _LVP_OFF & _BODEN_OFF
It switches WDT, BODEN and LVP off, sets oscillator to HS. Other options
are set by default.
>The other problem is that TMR1H does not seem to be writable. Since I'm
>trying to have an interrupt trigger when timer 1 overflows, this makes it
>difficult to gain any insight into what I'm doing wrong. At some point
>during the simulation, TMR1H gets the value 0x3E. I know of no code in my
>program that would write 0x3E to TMR1H. Attempting to change the value in
>the RAM window does nothing. Also, after the first breakpoint the trace
>window shows every subsequent instruction, even goto, reading 0x3E from
>TMR1H. An instruction that writes 0xFF to TMR1H is shown as simultaneously
>writting 0xFF and reading 0x3E from TMR1H. The same does not happen with
>the output to stdout; it doesn't report the read from TMR1H unless that is
>what the instruction is coded to do.
>
>
>
Hmm... strange behaviour... I don't know why it may happen. What's
version of your gpsim? I use 0.20.14.
>The program in question runs on the 16F628, and for extra debugging code,
>the 16F877A. I used the 16F628 code with gpsim.
>
>Is there a way around these problems?
>
>
>
--
Best regards,
Alex Ziranov.
Pyastra project: http://pyastra.sourceforge.net/
Rover project: http://www.handhelds.org/projects/rover.html
ICQ: 22365524
Jabber: estyler (at) plotinka (dot) ru
MSN: pyastra (at) hotmail (dot) com
[Content type application/x-pkcs7-signature not shown. Download]
