Exact match. Not showing close matches.
'[PIC] Memory address set to a value and unexpected'
|[Newbie alert, raise shields.]
I'm trying to drive a servo with a PIC18F458. PWM is generated in the timer interrupt handler, pulse length depends on the value polled from UART in the main loop and stored in a global variable.
Something weird happens.
The initial pulse length value is loaded in memory at the start of the program, expected pulse is generated (checked on the oscilloscope) and servo reaches position correctly.
When the new value is read from the serial, the pulse changes to the correct value for about a second (sometimes less, sometimes more), then (hear this) it goes back to the old length. What is going on?! Once the memory location that stores the pulse length gets overwritten with the new value, I'd expect the old one to be gone for good...
Relevant snippets follow, whole thing at
(pardon style -- or lack thereof -- and feel free to criticize warts other than the subject of this mail).
(Not familiar with banking, so I put everything into the access bank, that should be r/wable from everywhere.)
(Tried saving context with the fast stack register as well, no difference.)
_get_char ; read byte from serial and load value in PULSE_LENGTH
(Polling serial for received byte.)
Thank you for any light you can shed on this.
> When the new value is read from the serial, the pulse changes to the
> correct value for about a second (sometimes less, sometimes more),
> then (hear this) it goes back to the old length.
1st. Why did you put a "return" on line 60, right at the end of _loop ?
2nd. Your system is being resetted, first lets see if that's right, then we
figure out why. Try the following:
Right on top of main, but once you have configured all ports, put something
And hook up an LED to that pin so you'll see that secuence everytime your
system starts. AS you know, you should only see that one time when you turn
on the system.
Janso Desarrollos - Microchip Consultants Program Member
(54) 11 - 4542 - 3519
Thanks Russel for the heads up and Mauricio for the nice trick.
Watchdog, what a concept. After one ~7 hours of fruitless wandering,
I doubt I'll ever forget about it. :-)
> 2nd. Your system is being resetted, first lets see if that's right, then we
> figure out why. Try the following:
> Right on top of main, but once you have configured all ports, put something
> Bsf portpin
> Bcf portpin
> And hook up an LED to that pin so you'll see that secuence everytime your
> system starts. AS you know, you should only see that one time when you turn
> on the system.
Well, it turns out watchdog was not the only source of resets. I
cannot find where the rest is coming from, though. Below is the
minimum code that reproduces the problem (basically I poll RCREG until
I get something, then toggle the state of a led). I *guess* a reset
is what's happening because, if all went well, the led should be
turned on by sending one byte to the serial, then turned off with
another byte, and so on. Instead, it only flashes briefly whenever a
byte arrives. Can anyone point me in the right direction? (other
debugging techniques more than welcome as well).
__config _CONFIG1H, _HS_OSC_1H
__config _CONFIG2H, _WDT_OFF_2H
LEDPIN equ 0
LEDPORT equ PORTB
LEDTRIS equ TRISB
movlw 25 ; 9600 bps when clock @20Mhz
bsf TXSTA,BRGH ; high speed
bcf TXSTA,SYNC ; async
bcf TRISC,6 ; rc6 output
bsf TRISC,7 ; rc7 input
bcf RCSTA,RX9 ; 8-bit receive
bsf RCSTA,SPEN ; serial port enable
bsf RCSTA,CREN ; enable receiver
On Friday 26 August 2005 17:45, Max wrote:
> is what's happening because, if all went well, the led should be
> turned on by sending one byte to the serial, then turned off with
> another byte, and so on. Instead, it only flashes briefly whenever a
> byte arrives. Can anyone point me in the right direction? (other
> debugging techniques more than welcome as well).
Just to make sure it's not the WDT, you might add a clrwdt command into your
loops... (in case the programmer changed your fuse settings).. Also, add some
bit of code right at reset (maybe send a byte down the UART), to check that
it's being periodically reset and it's not some other random problem..
More... (looser matching)
- Last day of these posts
- In 2005
, 2006 only
- New search...