code for dual voltage 'window' on ADC input

[daveb0360]

Ok Enamul,
Code isn't working though.......gonna look into why, It looks as though the led is operating with reverse logic......my circuit is active low.....i.e. LED on when output low.....I tried simply changing the external properties but then no led lights at all....strange.

Dave

[daveb0360]

I Think I fried the PIC !!! can't get any code to work now...!!! Hell....
The AN3 pin only has 43mv on it.....!

Gonna try a different code.......In fact a short test code would be good I reckon....I'm thinking a loop that just pulses each output on and off in turn should be a good test to see if pic is fried.......any ideas?

Dave

[Enamul]

Hi,
That's very bad news. Good idea is to check with a basic pg. I can post one. just led on/off in porta<0>
Enamul

[daveb0360]

Yep, that's confirmed it, ran a short test code to pulse each I/O at 1 sec each..............code not running,
Think I know what's happened.
The 1uF caps I've got on the two adc inputs hold quite a bit of energy.......I think they've discharged into the pic on power down!.....at least, I hope that's all it is but it makes sense.......forgot the cardinal rule of I/O's, protect them from excess currents!!!

My own fault......gonna change the chip and add 1K resistors on a/d input pins before I go any further.

Dave

[daveb0360]

Ok.......Board repaired and modified. Programmed but code not functioning at all right using water_heater_Control1.fcf.... need to look into this
Done some static tests.
Voltage at the divider for the supply monitor gives the following.
Supply at:
14.02V gives 2.04V at divider
16.03V gives 2.34V at divider
26.99V gives 3.97V at divider
30.02V gives 4.42V at divider

This correlates very closely to simulation so is useful measurement to use for coding methinks

Dave

[Enamul]

Hi,
Although I am not clear why its not working as you said. This volts are useful for adc value. I guess last one is 30v not 20v
Enamul

[Enamul]

Hi,
I have modified the program to adapt with the voltage values...you can try it.
Enamul

[medelec35]

Hi, Since Enamul has kindly been helping you, I just thought I would debug my version (e.g if over voltage relay switches off.etc), and make some improvements for educational purposes.

I have reduce sample time to 2 seconds, and made voltage reading more accurate. so 29 is more like 29V and not 28V

Also to confirm board is operational when aroud set point, I has done led on for 99% and very briefly off for 1%

Watchdog timer has been set so of chip freezes program will be reset.

This has been tested with a 0 to 30V psu + 27K and 4k7 PD connected to AN2.

All permutations appear to be working, unlike previous version when completed deeper testing.

Martin

[daveb0360]

Hi Guys,
Thanks for all your efforts but I've now run out of patience.....can't get any code to work and now discovered why.......have also discovered why (or possibly why) my 617's are dying !
Partly, I suspect due to conflicting info from Microchip.
I use the Pickit2 programmer...I've used this on several past projects without issue. Suddenly, my 617's are failing after about the 3rd program cycle. I thought it was capacitive discharge so I hardwared that out with buffer resistors.
Still my 617's are frying.
Pickit 2 webpage gives an updated device file for use with V2.61 programmer software.......this supposedly give support for the F617!
I decided to look into this still further and discovered, when downloaded the lates version (8.86) of MPLab IDE........the device support list built into that, clearly states NO SUPPORT for the 617 using Pickit 2.
Same info on the latest download of supported devices...See here..

So, I don't know what exactly is not supported, but clearly, programming the 617's with the pickit 2 programmer, with latest OS and latest config files.........seems to destroy devices !!

So, I'm defaulting back to 12F675 if possible. I've used these before with pickit 2 without issue......and with multiple reprograms...
Sorry guys, I know you worked hard on these codes on my behalf but now I can't use the files or progress further..........sickening!

Dave

[Enamul]

Hi,
you can use pic12f675 no problem. Here is the code.
Enamul

[daveb0360]

Hi all,
Can anyone see any reason in my circuit why programming would be killing my chips? It's always MCLR that dies after 3rd or 4th programming attempt.
I think I need to re-design to use MCLR/VPP for programming only. I was thinking of adding a diode across the power supply pass transistor anode to emitter in case the Vpp programming voltage is somehow over-volting the PiC.

Any Ideas folks.....I'm running out of chips! lol.

Dave

[daveb0360]

Hi Martin,
I've tried your code and the thermal control loop works well, and the Voltage measurements and activity work pretty well...pretty darn accurate too. Unfortunately, the led blink patterns are all over the place, there are spurious blinks and patterns displayed that I can't make sense of.......It seems to simulate in Real Pic pretty well but on board, I can't make sense of it.......any ideas? All the supply rails are super stable and very low noise so I don't think it's actual noise pickup, just sensitive to single measurements.
I'm wondering if the various setpoints need to be averaged and slowed down in case the analog measurements are picking up spurious triggers or noise........can this be done? After all, The circuit is intended to function very slowly........nothing needs speed or immediacy. I'm thinking that each measurement needs to be taken every 3 seconds and averaged over 2 secs.

Sorry to be a pain. I'm sure you're sick of this now.

Dave

[Enamul]

Hi,
I was actually look at your front end of circuit.. I believe you are using ICSP with your current board...but if the pass transistor turned on in the running mode what will be the voltage in your Vdd pin and how much current will be passed in that pin!!...did you consider? Can you disconnect for the time being between Vdd and pass transistor emitter point...so that after programming there is no chance to get more than 5V in Vdd...another thing for the time being you can use internal MCLR so you don't need the MCLR connection with Vdd at all...so the circuit at least become safe...
Please update me your status..
Enamul

[medelec35]

Hi Dave,
With newer devices, they have a lower Vpp voltage requirement, but i didn't think that applied to 12F617.
But to play safe you could place a 10K resistor is series with VPP of programmer and VPP of Chip.

As for LEDs I tested with an external xtal of 19.66 MHz so I can use ICD function.

Circuit LEDS should not be affected by noise on the voltage line as there has to be the same consecutive condition for at least 2 seconds, but I can increase that.

Leave it with me and I will change pattern so its more distinctive. Open/ short sensor is similar to voltage>30

I will test patterns at 4MHz before posting, just to make sure all are correct.

You can try programming a 617 several times even if its the same program with the 10K in series as stated earlier, just to see if that works.

If if does then 617 can be used otherwise I will try and get it on 12675

As a tip What i do is use RS232 to send values of variables to a pc with a terminal program on, so I can view in real time what's going on.
For instance if still using 12F617, and there is a spare o/p, you can see what voltage is on the i/p.
You can also see what the reported temperature is.
Just food for thought.

[daveb0360]

Hi Enamul,
Being relatively new to PIC's I decided to read the datasheet properly !
It seems my problem is self inflicted.............no surprise there!
The datasheet specifies certain parameter requirements fo MCLR/Vpp pin, firstly..
An internal MCLR option is enabled by setting the
MCLRE bit in the Configuration Word. When enabled,
MCLR is internally tied to VDD. No internal pull-up
option is available for the MCLR pin.
Now then, I have been enabling this MCLR function before programming......it seems, wrongly.....this has allowed the Vpp voltage an internal route to VDD......hmmm

Also, my supply front end, although extremely stable......necessary for reliably accurate A/D performance, it also rises very quickly....faster than the pic likes! ....
The on-chip POR circuit holds the chip in Reset until
VDD has reached a high enough level for proper
operation. To take advantage of the POR, simply tie the
MCLR pin through a resistor to VDD. This will eliminate
external RC components usually needed to create
Power-on Reset. A maximum rise time for VDD is
required. See Electrical Specifications for details (see
Section 12.0 “Electrical Specifications”). If the BOD
is enabled, the maximum rise time specification does
not apply. The BOD circuitry will keep the device in
Reset until VDD reaches VBOD (see Section 9.3.5
“Brown-Out Detect (BOD)”)
So, I conclude that if I set the BOD option to enabled, the device is no longer dependent on VDD rise time.

And just read this too......
The Power-upTimer should always be enabled when Brown-out
Detect is enabled.

Therefore, if I disable internal MCLR and enable BOD and PUT, my problem of frying the chips should go away.......(he says hopefully. )
If this works, I can go back to concentrating on the code.
So this is how config options set for my hardware....what do you think?


Dave

[Enamul]

An internal MCLR option is enabled by setting the
MCLRE bit in the Configuration Word. When enabled,
MCLR is internally tied to VDD. No internal pull-up
option is available for the MCLR pin.

That's sound reasonable for frying the pics after first write...good point noticed..in fact I always use EB006 programmer which don't have those issues..
In my products I never use ICSP feature because of this risk as my employees will fry chips often then....my employees still use parallel port programmer..they say old is gold..as that perform superb.

I have analog hang protection circuitry that I designed earlier and I include always in my every design and works fine in thousands of PIC circuits in customer premises and never use watchdog timer that's why..I always prefer pic internal Power-up timer...

I have shared what I like and use..plz don't take it anyway
Enamul

[daveb0360]

Hi Enamul,
Your secrets safe with me...

Dave

[medelec35]

Here is code on a 12F675
LED duration are as follows:
Stand by: 2.5 secs off, 65ms on
Thermistor Fault: 4.36Hz
Over Temp: 1.5Hz
Over Voltage 1/2 Hz
At set point: 1.7Secs on and 16.3 ms off
Can easily change on/off times or frequencies to any specification.

Martin

[daveb0360]

Hi Martin,
Still can't get the led to behave. First mystery was the led logic is upside down........I sorted that, just inverted the timings within the switch matrix.......simples!

However, the led patterns do not seem to be selecting correctly and seem to be spurious. The standby function is fine but this pattern rarely changes and when it does, it seems to be spurious.

I don't understand it at all. I've had the scope on the various nodes and supplies but all is stable..........I'm clueless and fed up that I don't understand how your code is working sufficiently to debug it..........assuming it needs debugging.
The Supply voltage detection points and thermal control points are really good and pretty accurate. The overvoltage pattern works OK (although it isn't strictly needed), the 'constant on' pattern does'nt work at all when at temperature...it just continues with the standby pattern with the odd spurious flicker thrown in.

I wish I could video it working so you could see. Such a shame because the basic control functions such as temperature loop and voltage detection, work fine........just the led patterns are unreliable.

Sorry to trouble you.......

Dave

[medelec35]

Hi Martin,
Still can't get the led to behave. First mystery was the led logic is upside down

Ah sorry my mistake, I did not see that if heater can be enabled due to correct voltage then blink for 1/2 second. Some how it was sill in my mind that you stated rapid flash if over voltage.
I have not looked at your pic of conditions properly.

I have altered that bit of code.
So now its:

Code: Select all

Stand by: 2.5 secs off, 65ms on (heater inactive as voltage is out of range)
Voltage within range so heater can be enabled and no over-temperature or thermistor fault: Flash 1/2 Hz
Thermistor Fault: 4.36Hz
Over Temp: 1.5Hz
Over 30V same as standby
At set point: 1.7Secs on and 16.3 ms off

As for the flickering that could be caused by ADC value keeps changing by +/- 1 digit whilst voltage stays constant.if causes going from 1 condition to the other, that will cause havoc with pattern.
This won't happen on voltage detection side due to averaging but could happen on temperature reading side. one way round is
I have changed Water_Temperature<=39 to Water_Temperature<39
See if that sorts out issue.

For simulation
If you look at Real pic sim.
Voltage low byte is at address 39h
So If Slider connected to An2 is at 466 for example, you can see 39h = 16.
Therefore 16V is being detected.

If you still have problems, measure voltage on both ADC i/p s to chip, Let me know the voltages measured and what you get and what you expect then I can sort that out for you.

Hope this flowchart solves all issues!

Martin

[daveb0360]

Hi Martin,
Couldn't get this latest version to work at all.............the led played dumb and then I spotted why.....somehow an error crept in to the timer section allocating led to port B....which of course, the chip doesn't have a port B.......simple to correct... but still I don't get steady LED patterns, It's improved but not stable at all. Voltage and temperature range detection seems fine but the led patterns are not at all as expected.
Is there any way of applying the same averaging algorithm to the the temp measurements......I can't decipher how this works otherwise I would attempt to sort this myself.

What kind of pattern can be placed in these 'calculation' boxes..........could I perhaps have a double flash, delay, double flash type pattern?

I think......ermmm.. I KNOW now, that coding is way above my abilities if anything other than simple state machine is required..........I have spent hours pouring over the LUT procedure and can't fathom the technique at all.........I can just work out how the values in the table are arrived by........but I can't fathom how it is used in the program.......one day, when the urgency of this job is out of the way, I will try harder to understand this.

Incidentally, I solved the frying chips scenario by using the 'On the Go' feature of PICKit 2 and setting 'VPP First' function. I take the programmer to the board on the bench instead of taking the board to the PC. I don't know why this has made a difference but it has; I have now flashed the proto board a dozen times or more and it's still running
Dave

[medelec35]

the led played dumb and then I spotted why.....somehow an error crept in to the timer section allocating led to port B....which of course, the chip doesn't have a port B.......simple to correct

Sorry about that, I was testing on hardware (not 12F675) and was using port B, and thought I had changed it back.

As for random patterns, since it was working ok on my hardware using a pot, could you have a floating i/p to temperature side of ADC?
This would cause random patterns as voltage will be all over the place.

A dry joint, open circuit or tracking is going to wrong ADC.
You could quick check by say creating a PWM where duty is determined by voltage across ADC on the temperature side PWM can be measured with a scope.
Or just keep measuring directly on pin 3 (An3) of chip.
If Voltage is steady on pin 3 of chip, as stated before if u let me know the voltage on both pins, and what the LED is doing then I can place same voltages on my hardware and take it from there.

[daveb0360]

Hi Martin,
I've PM'd you with a video link to the unit on the bench.
It would seem that the problem is mainly when at temperature.
There could be an anomaly in the requirements I was thinking.

We want an upper limit of 45c at which point, the heater will default off. Heatsoak caused by thermal mass of the heater....(a 15ohm power resistor) causes the heat to continue to rise for a while after heater current is switched off. However, the overtemp routine doesnt indicate till setpoint (45c) +10C = 55c........this no mans land....between 45c and 55c has no control or indication. The water temp is still 'safe' so should indicate with a solid 'on' led. The program knows the temp has gone past setpoint but it hasn't reached the overtemp point.

Don't know if there is an issue here that could cause this bizarre behaviour of the LED which also seems to worsen as the temp is falling back.

Dave

[medelec35]

Hi Dave,
After watching that video,I have got several theory's.
To me it looks like your chip keeps resetting?
You can confirm this by loading in attached file.
I I did was to put a start up routine to tell if chip is resetting:
Flash 3 times at 1HZ
solid on for 3 secs
solid off for 3 secs

When ever chip resets, it ill go though above sequence again.


If this is the case then try putting something like 100uF across VDD and VSS of chip.

Once you loaded code, we can take it from there as I could be wrong so will try a different theory.
Re changing so solid until 55C
Pattern 2 is used for solid on.
Just change the <48 value of (Water_Temperature>39)&& (Water_Temperature<48)
to (Water_Temperature>39)&& (Water_Temperature<55)
Did it that was as you have only got conditions from 40 to 45 and exceed 55C

Martin

[daveb0360]

Hi Martin,
The code you presented goes absolutely berserk ! Although it didn't go through the test routine multiple times....
I added extra capacitance as suggested but this just makes the psu unstable.......then it goes wild so that's a non starter.
Without the capacitance, using a scope, I see microscopic dips in the rail of 145uV during led 'on' times, nothing even close to what is needed to reset the pic, or affect measurements.

I've been looking at the exported 'C' code and whilst I confess to knowing zip all about c, I did read a few errors in the code........how significant these are, I have no idea. I've pasted them below.

#warning "This interrupt has previously been enabled, so the macro <Timer0_Tick> may never get called."
#error "ADC Type 5 conversion code error - please contact technical support"
#error "Target device is currently using AN1 for VREF+"

I'll flash it again as I'm not sure I set config bits properly first time round.....keep forgetting!

Dave