Shop OBEX P1 Docs P2 Docs Learn Events
Lockup in Repeat... — Parallax Forums

Lockup in Repeat...

Dave D'AmatoDave D'Amato Posts: 6
edited 2011-08-08 06:59 in Propeller 1
Hey all,

First post so here goes...

CODE: High Voltage Discharge circuit.
Small extract on completed code for figguring this issue out...

40 Pin Propeller w/5Mhz crystal, w/24LC256 and Propeller Clip interface to USB...


CON
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000

propTX = 30 ' programming output
propRX = 31 ' programming input
propSCL = 28 ' external eeprom SCL
propSDA = 29 ' external eeprom SDA
TRIGOUT = 1 ' Trigger output to SCR
SSR = 2 ' Drive SSR (+)

VAR
byte Decode_Pos_0 ' PO TRIGGER INPUT

pub start
dira[TRIGOUT]~~
outa[TRIGOUT] := 0

dira[SSR]~~
outa[SSR] := 1

dira[Decode_Pos_0]~

repeat
Decode_Pos_0 := INA[0] 'PO Trigger Input
IF Decode_Pos_0 == 0
outa[TRIGOUT] := 1 ' SCR Triger ON !
outa[TRIGOUT] := 0 ' SCR OFF !
outa[SSR] := 1
waitcnt (30_000 * 100 + cnt) ' ~ 36ms (20_000 * 100 + cnt)


As can be reviewed fairly simple....
What's occurring is for the most part works as expected then all of a sudden, it discharges then will not reset after the waitcnt... Lost in limbo...

Decode_Pos_0 is just a 3.3Vdc input via switch, triggers the cirucit, HV discharges as expected... Most of the time anyways...

O-scope screen capture...

On the right is exactly what's supposed to occur.. D-charge the high voltage, wait ~ 40msecs then recharge back to high voltage. The cycle on the left is where it itermittently locks low for ~ 1.4 seconds then refreshes. The 1.4 seconds is fairly consistent when it occurs. Other times it locks permittently until F11 EEPROM reload is accomplished...

All code is aligned...

Any ideas appreciated...

Thanks,

Dave D'Amato
640 x 480 - 64K

Comments

  • Duane DegnDuane Degn Posts: 10,588
    edited 2011-08-05 18:44
    Dave, Welcome to the forum. It would help if you edited your post to display the code correctly.

    Follow this link to learn how.

    attachment.php?attachmentid=78421&d=1297987572
  • PliersPliers Posts: 280
    edited 2011-08-05 19:41
    My bet would be that it is an electrical noise issue due to the high voltage and current discharges.
    Is the SCR trigger opto isolated?

    Can you share some diagrams?
  • edited 2011-08-06 06:49
    Yup on the opto isolation trigger to SCR as well as using isolated power grounds....

    I originally was using the BS2.functions and went with waitcnt to see if it made a difference. I also tried using pause/waitcnt in usec and msec after the call to see if this was the cause of the lock up, both with no change.... It's ;like it discharges and the code goes "Oh Smile, I forgot what I was doing".... My code is Stoned! DOH!

    Unfortunately due to this being a consumer design (work) I'm not allowed to share the circuit schematics... Sorry.

    The main code also controls the high voltage maximum user defined settings that works flawlessly... Just this damn trigger lock up... lol!
    The real curious thing is why 1.4 secs when it does occur.... Should put a audio alert where possibly the code is rebooting or something.

    Ah well, I'll keep pluggin away and report any findings that may fix this issue.... May have to re-code using PropBasic to see if that also is effected...

    If nothing else, I could go back to the BS240 chips we have been using all along and see if the problem still occurs.
  • kuronekokuroneko Posts: 3,623
    edited 2011-08-06 16:47
    repeat
        Decode_Pos_0 := INA[0]                          'PO Trigger Input               
        IF Decode_Pos_0 == 0
              outa[TRIGOUT] := 1                            ' SCR Triger ON !
              outa[TRIGOUT] := 0                            ' SCR OFF !
              outa[SSR] := 1
       waitcnt (30_000 * 100 + cnt)                     ' ~ 36ms  (20_000 * 100 + cnt)
       [COLOR="red"]!outa[LED][/COLOR]
    
    I hope I recovered the main loop as originally intended. Would it be possible to add an LED or at least scope a separate pin which is toggled for each loop run? This is to verify whether we are still in the loop during that 1.4sec delay.

    Something just occurred to me. The boot delay from EEPROM is about 1.3sec which suggests that the chip is actually reset for as yet unknown reasons. What's your situation re: bypass capacitors etc (for the prop)?
  • JonnyMacJonnyMac Posts: 9,208
    edited 2011-08-08 06:59
    After you've sorted the power issues mention above, you may want to use waitpne to look for the pin to drop.
    repeat
        waitpne(|< 0, |< 0, 0)                              ' wait for P0 to drop
        outa[TRIGOUT] := 1                                  ' SCR Triger ON !
        outa[TRIGOUT] := 0                                  ' SCR OFF !
        outa[SSR] := 1
        waitcnt ((clkfreq / 1000 * 36) + cnt)               ' ~ 36ms (20_000 * 100 + cnt)
    
Sign In or Register to comment.