Searching \ for '[PIC] Memory address set to a value and unexpected' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: piclist.com/techref/microchip/memory.htm?key=memory
Search entire site for: 'Memory address set to a value and unexpected'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Memory address set to a value and unexpected'
2005\08\25@085117 by Max

picon face
[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
http://rafb.net/paste/results/Bduue556.html
(pardon style -- or lack thereof -- and feel free to criticize warts other than the subject of this mail).

       cblock  0x00
       WREG_TEMP
       STATUS_TEMP
       BSR_TEMP
       PULSE_LENGTH
       endc

(Not familiar with banking, so I put everything into the access bank, that should be r/wable from everywhere.)

_interrupt_handler
_interrupt_handler_context_save
       movff   STATUS,STATUS_TEMP
       movff   WREG,WREG_TEMP
       movff   BSR,BSR_TEMP
       movlw   PWM_PERIOD
       movwf   TMR0L
_interrupt_handler_actuation
       bsf     PORTC,ACT_PIN
       movf    PULSE_LENGTH,W
       call    _delay
       bcf     PORTC,ACT_PIN
_interrupt_handler_context_restore
       bcf     INTCON,TMR0IF
       movff   BSR_TEMP,BSR
       movff   WREG_TEMP,WREG
       movff   STATUS_TEMP,STATUS
       retfie

(Tried saving context with the fast stack register as well, no difference.)

_loop
       call    _get_char
       goto    _loop
       return

_get_char                       ; read byte from serial and load value in PULSE_LENGTH
       nop
       btfss   PIR1,RCIF
       goto    _get_char
       movff   RCREG,PULSE_LENGTH
       return

(Polling serial for received byte.)


Thank you for any light you can shed on this.

Max

2005\08\25@090923 by Russell McMahon

face
flavicon
face
> 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.


Watchdog?


2005\08\25@091010 by Mauricio Jancic

flavicon
face
Hi,

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
like:

Bsf portpin
Delay1sec
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.

Kind regards,

Mauricio Jancic
Janso Desarrollos - Microchip Consultants Program Member
spam_OUTinfoTakeThisOuTspamjanso.com.ar
http://www.janso.com.ar
(54) 11 - 4542 - 3519

2005\08\25@093450 by Max

picon face
*slaps forehead*

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. :-)

Max

2005\08\26@124518 by Max

picon face
> 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
> like:
>
> Bsf portpin
> Delay1sec
> 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).


       list    p=18f458
       include "p18f458.inc"

       __config _CONFIG1H, _HS_OSC_1H
       __config _CONFIG2H, _WDT_OFF_2H
       radix   dec

LEDPIN  equ     0
LEDPORT equ     PORTB
LEDTRIS equ     TRISB

_main
_setup_io
       bcf     LEDTRIS,LEDPIN
       bcf     LEDPORT,LEDPIN
_setup_serial
       movlw   25              ; 9600 bps when clock @20Mhz
       movwf   SPBRG
       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
_loop
_get_char
       nop
       btfss   PIR1,RCIF
       goto    _get_char
       movf    RCREG,W
       btg     LEDPORT,LEDPIN
       goto    _loop

       end

2005\08\26@142507 by Shawn Tan

flavicon
face
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..

cheers..

--
with metta,
Shawn Tan

More... (looser matching)
- Last day of these posts
- In 2005 , 2006 only
- Today
- New search...