Software PWM lockup on a 16F877A


Closed Thread
Results 1 to 14 of 14

Hybrid View

  1. #1


    Did you find this post helpful? Yes | No

    Default

    right, i changed the PWM to use TMR2 and it still locks up...
    The only thing i can think of now is to start disabling some of the routines to isolate the problem...

    Can no one shed any light on this?

  2. #2
    Join Date
    Apr 2007
    Posts
    34


    Did you find this post helpful? Yes | No

    Default

    just a quick glance -

    Code:
    SOFTPWM:
    IF Mode > 0 then 
        goto SOFTPWMAUTO
        ELSE
        GOTO SOFTPWMMAN
        ENDIF
    
    @ INT_RETURN
    RETURN
    shouldn't that be gosub softpwm... because otherwise it will not come back and process the @ INT_RETURN?

    just a guess

  3. #3


    Did you find this post helpful? Yes | No

    Default

    Call me a Muppet and stripe me pink!

    I could have sworn they were gosubs! Honestly... i seen gosubs...
    Well spotted!

    I'll re-program in the morning...

  4. #4


    Did you find this post helpful? Yes | No

    Default

    ok... getting annoyed!
    Changed the goto's to gosubs... same fault...
    Disabled BOTH interupts so that all it has to do is flash an LED using pauses... same fault...
    I've disabled the watchdog, power on timer, brownout reset and LVP and it still does it...

    i'm seriously lost now... Help needed

  5. #5


    Did you find this post helpful? Yes | No

    Default

    Just for the hell of it... I tried another PIC same model and it does it on that too...

    Any help is VERY appreciated

  6. #6


    Did you find this post helpful? Yes | No

    Angry

    You are not going to believe this!

    i tried a test program, disabled analog, turns all ports to output, sets all ports to low and then enters the same loop to toggle the LED... SIMPLE!
    It failed and locked up...

    so i asked myself, what is the diference between the 3mm red LED on PORTB.7 and the one on PORTD.0? so i switched them over... same result...

    Just for the hell of it, i switched the resisters over and tried it... and it works!
    I switched the resisters back and it locks up...

    I took the suspect resister out and stuck it on my multimeter... it read less than 1ohm!
    The resisters are supposed to be 68 ohms... this one is a faulty one...

    So, the problem must have been caused by too much current through one of the IO lines...
    I have lost 4 days trying to debug a problem caused by a 5 pence component that i would have never suspected if i was anywhere near sane!

    So now i'm going to re-enable all my code and try it... god darn it!

  7. #7
    Join Date
    Apr 2007
    Posts
    34


    Did you find this post helpful? Yes | No

    Default

    Haha good to hear you found a problem!
    I know that feeling too well, you're not alone!

  8. #8
    Join Date
    Feb 2006
    Location
    Gilroy, CA
    Posts
    1,530


    Did you find this post helpful? Yes | No

    Default

    Quote Originally Posted by masosi View Post
    just a quick glance -

    Code:
    SOFTPWM:
    IF Mode > 0 then 
        goto SOFTPWMAUTO
        ELSE
        GOTO SOFTPWMMAN
        ENDIF
    
    @ INT_RETURN
    RETURN
    shouldn't that be gosub softpwm... because otherwise it will not come back and process the @ INT_RETURN?

    just a guess
    Except, we are not supposed to gosub outside of our interrupt handlers.
    See: http://www.picbasic.co.uk/forum/show...3788#post83788

    Does it work for you, or is it acting funny?

  9. #9
    Join Date
    Oct 2005
    Location
    Sweden
    Posts
    3,612


    Did you find this post helpful? Yes | No

    Default

    Well, that's true if you jump out of the ISR never to RETURN to it. You can definetely GOSUB "out of" the ISR as long as you don't "wander off" and doesn't RETURN to within the ISR to finally end up at the INT_RETURN.
    Code:
    myINT:
      GOSUB mySUB1
      GOSUB mySUB2
      TOGGLE PortB.0
    @ INT_RETURN
    The above will work just fine as long as mySUB1 and mySUB2 RETURN to within the ISR.

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


    Did you find this post helpful? Yes | No

    Default

    With 18F's or 16F1's, you can get away with GOSUBing to other routines from the interrupt handler.

    But with 12F's and 16F's, you are limited by a very small Stack (8 levels).
    Most PBP statements only use 1 or 2, but a couple of them can use up to 4 levels, which only leaves 4 levels for your program and it's GOSUB's.

    When you get an interrupt, the hardware itself uses 1 level.
    When the interrupt happens, it could be 2 or 3 gosubs deep already in your main program.
    Then using Basic Language statements in the interrupt handler will want some more levels.

    If you use another level by gosubing from the handler, then you are really pushing your luck.
    It may work fine for some programs, but it could be catastrophic for others.

    With 18F's and 16F1's, there are plenty of stack levels to go around. But not with the "little" guys.
    DT

  11. #11


    Did you find this post helpful? Yes | No

    Default

    So far, she does run... however, i'm having a right mare with the comms hardware setup and the comms handler...(shakes head)
    Now that i have 6 18F4550's from crownhill i may revert the program back to using them...
    The program does sweet FA, everything is driven from interrupts, their is only the 'automatic' and 'manual' modes that have gosubs and they are correctly returned so i don't think it's over/under runs that are the problem now...

    I'll post more info later on, I'm going to take a break for a couple of hours and have a blast on CnC...

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