Context saving in assembly - 16F72 giving problem


Closed Thread
Results 1 to 7 of 7

Hybrid View

  1. #1


    Did you find this post helpful? Yes | No

    Default Re: Context saving in assembly - 16F72 giving problem

    Anyone there?
    ___________________
    WHY things get boring when they work just fine?

  2. #2
    Join Date
    Nov 2003
    Location
    Wellton, U.S.A.
    Posts
    5,924


    Did you find this post helpful? Yes | No

    Default Re: Context saving in assembly - 16F72 giving problem

    Quote Originally Posted by financecatalyst View Post
    Anyone there?
    Nope, no one here.
    Dave
    Always wear safety glasses while programming.

  3. #3


    Did you find this post helpful? Yes | No

    Default Re: Context saving in assembly - 16F72 giving problem

    Great!!
    ___________________
    WHY things get boring when they work just fine?

  4. #4
    Join Date
    Jul 2003
    Location
    Colorado Springs
    Posts
    4,959


    Did you find this post helpful? Yes | No

    Default Re: Context saving in assembly - 16F72 giving problem

    Somebody's home, but that doesn't mean the lights are on.

    I notice that you aren't saving PCLATH.
    It would depend on what's in your ISR whether you need to save it or not, but you didn't include that part.

    $40 is fine for the wsave variable in all banks.

    Make sure the interrupt flag is cleared before exiting the ISR.
    DT

  5. #5


    Did you find this post helpful? Yes | No

    Default Re: Context saving in assembly - 16F72 giving problem

    Thanks Darrel, here is my complete code:
    ISR:
    asm
    movwf wsave ; Save WREG
    swapf STATUS, W
    clrf STATUS ; Point to bank 0
    movwf ssave ; Save STATUS
    movf FSR,w
    movf fsave ; save FSR

    BTFSS INTCON,TMR0IF
    GOTO EndInt

    bcf INTCON, TMR0IF ; clear the interrupt
    incf _i
    movlw 3
    bcf STATUS,Z
    XORWF _i,w
    BTFSS STATUS,Z
    Goto EndInt

    clrf _i

    bcf STATUS,Z
    MOVLW 0
    addwf PORTA,w
    BTFSS STATUS,Z
    clrf PORTA

    BCF STATUS,Z
    MOVLW 0
    addwf PORTC,w
    BTFSS STATUS,Z
    clrf PORTC

    EndInt ; restore the machine state and return from interrupts
    movf fsave,w
    movwf FSR ; restore FSR
    swapf ssave,w
    movwf STATUS ; restore Status
    swapf wsave,f
    swapf wsave,w ; restore WREG
    retfie
    endasm
    My PIC just hangs. The oscillator pins get weird constant voltage levels, one ground, one at 4.7/4.8 volts. The code is just clearing PORTA/C after certain interval.

    I would also take this opportunity to ask you one question which I have heard before as well but never understood completely which is -> WHY should I save PCLATH? The datasheet says
    During an interrupt, only the return PC value is saved on the stack. Typically, users may wish to save key registers during an interrupt (i.e, W, STATUS registers)...
    and it also provides few lines about context saving.
    ___________________
    WHY things get boring when they work just fine?

  6. #6
    Join Date
    Jul 2003
    Location
    Colorado Springs
    Posts
    4,959


    Did you find this post helpful? Yes | No

    Default Re: Context saving in assembly - 16F72 giving problem

    Good question!

    It's one of those things that was in the book since forever and I never questioned it. Just went on using it.
    But now that you ask, and I look for the correct answer ... I can't see where it's needed on a chip with 2K or less.

    GOTO and CALL statements encode 11 bits of the address into the opcode, and 11 bits covers the full 2K.
    There's no reason for it to use the upper 2 bits, and therefore you shouldn't need to save PCLATH.

    I'll ask Jeff (he's out of town right now) and see if he had a reason for it.

    Since your ISR doesn't use the FSR, you don't need to save/restore it either.

    But back to your problem ...
    If the oscillator stops running, it sounds like a sleep instruction was executed.
    Do you have any SLEEP's in your code.

    Or maybe the MCLR pin is being pulled low somehow. Check the voltage on MCLR when the problem happens.

    Possibly a brownout condition, check VDD voltage when the problem happens.
    DT

Members who have read this thread : 0

You do not have permission to view the list of names.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts