Lockup in Repeat...
Dave D'Amato
Posts: 6
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
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
Comments
Follow this link to learn how.
Is the SCR trigger opto isolated?
Can you share some diagrams?
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.
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)?