Hi
I have hit a Interrupt on change problem with the pic 16F1828 that is mystifying me. I cut the code down to similar to the example in: https://sourceforge.net/p/gcbasic/discussion/579126/thread/f4f450da/#d8bc
but am using Set IOCAP0 On : Set IOCAN0 On : Set IOCAP1 On : Set IOCAN1 On. Which should give me rise and fall detection.
In the Interrupt handler, flags IOCAF0, IOCAF1 are being cleared.
The input switching can be seen on a scope to be going between 0V and Vcc.
When the pic is running from VCC > 3.1V it works as expected However when the vcc is reduced to < 3.0 the Interrupt on change operation gets more variable until at around 2.5V the interrupts stop working.
The PIC is running on internal clock at 2Mhz. When everything else is put back in it all works down to 2.5V except for the interrupts on change. The inputs are being correctly read in.
It looks like the Interrupt on change does not work below a VCC of 2.9V very strange, but the chip spec is operation down to 1.8V.
I am clearly missing something could you point me in the right direction please.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
More information needed! Is a button or switch being monitored, or is it an incoming waveform. What is the mode of operation, frequency, and purpose of the operation.
You can operate both PORTA and PORTB interrupt on change pins for the 16f1828 now? Can the bug report be closed?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I had this email prepared to send but wanted to try some things out before
sending and in the meantime received your email.
As far as the bug report is concerned I suppose we should close it. It may
be worth adding something to the documentation somewhere otherwise the
question will come up again.
I not sure where in the documentation you would place the note. The first
place I looked was the help, the second the chip data for the device.
Just a thought but how about adding a simple text note in the chip data.
With reference to your question.
The device is normally in sleep it wakes up from sleep every 16 Seconds
(Timer-1 and 32kHz Crystal) or when one of the switches is changed by hand (
Interrupt on change brings out of sleep). Waits for 100mS (Timer 0) so that
any contact bounce has finished and then monitors the input Pins state (Port
A0 and Port A1). The rf device is then woken up and the input pin states are
sent out via the serial port to an rf device. Once the data has been sent
(approx 24mS) the PIC goes back to sleep. The pic in sleep is taking <
5uA.
The two switches are being operated by Hand and are simple single pole two
way switches connected to either Vcc via a 4.7k pull up or 0V. So each that
input is going either from 0V to Vcc or Vcc to 0V. The inputs also have
Schottky diode input protection, the wire length to the switches is approx
3".
The purpose of the interrupt on change is just to wake the device up from
sleep. The switches are operated by hand not machine so the max frequency of
operation will be around 50-100mS. I am switching them every few seconds.
At VCC between 2.5V and 3.6V the switches are always correctly read when the
device wakes up from sleep every 16 Secs (This will be changed to hours
latter)
At vcc =3.3V everything works fine, The packets arrive correctly with the
correct numbers in them as the switches are changed.
At vcc of 2.5V the device wakes up when the switches are activated but the
data is filled 0 or sometimes the correct data is displayed and the it
changes back to 0.
A couple of things I have noticed today, an LED indicator added shows that
when the switches are activated it always comes out of sleep which is good.
The other thing I have noticed is an interaction with timer 0. If I disable
the de-bounce code it seems to work reliably down to 2.5V. I have been
looking at it on and off all day
but cannot pin-point the issue. Perhaps there is a bug in my code somewhere.
I cannot make the mental connection between the problem and why it would be
supply dependant in a digital system.
For your information I am knocking down the voltage using the PicKit 2 S/W.
2.5V is the lowest it goes. I have a swictch that disconnects the inputs
from the pic programmer so that the pic-kit 2 does not pull down the inputs.
I will have another look tomorrow.
Hope I have answered you questions.
Thanks for the help.
From: kent_twt4 [mailto:kent_twt4@users.sf.net]
Sent: 19 April 2015 12:07 AM
To: [gcbasic:discussion]
Subject: [gcbasic:discussion] Pic 16F1828 Interrupt on change not working at
supply voltages < 3V, everything else works well.
More information needed! Is a button or switch being monitored, or is it an
incoming waveform. What is the mode of operation, frequency, and purpose of
the operation.
You can operate both PORTA and PORTB interrupt on change pins for the
16f1828 now? Can the bug report be closed?
1) Can switch operation be converted over to a momentary pushbutton, or just use the switch in a negative going pulse? This would be single ended operation and clean up my doubts about having the negative and positive IOC at the same time.
2) Try mechanical debouncing with a 0.1uf (Or?) cap, and ditch the software debouncing?
2) If the schottky diode is inline then you could be losing .5V to .7V on the switch signal, leaving it an unreliable voltage zone? Wouldn't think you would need it?
3) I know from using a ttl UART converter at sub 3V voltage levels, that signal integrity, or the signal voltage can lead to failed transmissions. So from that standpoint, check the RF data sheet to see the minimum high level voltage you can work with.
4) Extra supply bypass capacitance? RF devices can be power hogs, so add an extra 47uf, 100uf cap?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
After many hours the problem seems to be traced to the BOREN.
With BOREN On or Off it all works down to VCC OF 2.55V. (I still have the
100uf capacitor on vcc as a precaution, not that it made any difference)
With BOREN set to BOREN=NSLEEP I see issues. What seems to be happening is
the code is breaking out of the main program and starting at the first line,
I suspect this is a device reset.
I have tried BORV = 1 '1=1.9V, 0=2.5v Typical. Which made no difference in
BOREN=NSLEEP.
I have also tried waiting for BORRDY=1 'which also made no difference.
So as BOREN On use a lot of current I am tempted just to switch it off.
I am not to sure what the implications are, this is a battery operated
board, the rf will pack up at ~2V anyway and the battery will be near end
of life at 2- 2.5V. So I am tempted to call it a day on this problem and
move on.
Have you come across BOREN NSLEEP issues before. This is an area I have no
experience in.
Thanks
Steve
From: kent_twt4 [mailto:kent_twt4@users.sf.net]
Sent: 20 April 2015 1:01 AM
To: [gcbasic:discussion]
Subject: [gcbasic:discussion] Re: Pic 16F1828 Interrupt on change not
working at supply voltages < 3V, everything else works well.
@Stephen: A few of things I can think of:
1) Can switch operation be converted over to a momentary pushbutton, or just
use the switch in a negative going pulse? This would be single ended
operation and clean up my doubts about having the negative and positive IOC
at the same time.
2) Try mechanical debouncing with a 0.1uf (Or?) cap, and ditch the software
debouncing?
2) If the schottky diode is inline then you could be losing .5V to .7V on
the switch signal, leaving it an unreliable voltage zone? Wouldn't think you
would need it?
3) I know from using a ttl UART converter at sub 3V voltage levels, that
signal integrity, or the signal voltage can lead to failed transmissions. So
from that standpoint, check the RF data sheet to see the minimum high level
voltage you can work with.
4) Extra supply bypass capacitance? RF devices can be power hogs, so add an
extra 47uf, 100uf cap?
The BOREN config bits should not really have a bearing on causing a device to reset from sleep. Using the INT pin as an interrupt from sleep it always continues on from where it left off (i.e. no reset), regardless if BOREN is ON, OFF, or NSLEEP. I would leave it off and monitor the battery voltage with an a2d pin.
Presumably you are using the Timer1 overflow interrupt? This method is supposed to work by executing the next instructions. So definitely at a loss as to why the reset.
I always use a nop after sleep to make sure the next instruction is not executed for whatever reasons.
If you happen to be using rechargeable Li-ion, then 2.5v should be treated as the very minimum, preferably higher (e.g. 2.8V-3.0V), otherwise risking damage to the battery.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
First Thanks for your help, knowing some has made it work and who has good
ideas of things to look at is a big help.
I implemented a S/W BOREN and traced down the issue to the RF module
switching on and off (as you suspected). The monster capacitor helps, but is
not the solution and is not practical for me. Looking at the battery data
sheet it has a series resistance of 6.3 ohms at 30mA which leads to a change
in supply rail just enough to trigger the Brown out detector even with a
fair bit of decoupling. The voltage change and response do not look that bad
so I cannot say for sure if it is the level or rate of change or both that
are doing the damage.
With a 3.6V battery having a series R of 6.3 ohms at 30mA together with
temperature and aging I have come to the conclusion that the BOR is just not
suitable for low voltage battery apps and have switched it off.
The unit is working nicely down to 2.2V which give me enough headroom for a
3.6V Battery. Current consumption is 3uA (Sleep) to 30mA (TX).
In the past couple of days I have come across a microchip app note that says
BOR is not recommended for battery application.
I hope this helps the next person who comes across this type of problem.
You suggested to use an A To D to generate a low voltage Alarm, but I think
this requires using the internal voltage reference and the GC ADFormat does
not have this option, I had a look at the include file but it looks a bit
beyond me at the moment. Have you come across a good example that I can use
as a starting point.
Thanks again.
From: kent_twt4 [mailto:kent_twt4@users.sf.net]
Sent: 24 April 2015 2:05 AM
To: [gcbasic:discussion]
Subject: [gcbasic:discussion] Re: Pic 16F1828 Interrupt on change not
working at supply voltages < 3V, everything else works well.
The BOREN config bits should not really have a bearing on causing a device
to reset from sleep. Using the INT pin as an interrupt from sleep it always
continues on from where it left off (i.e. no reset), regardless if BOREN is
ON, OFF, or NSLEEP. I would leave it off and monitor the battery voltage
with an a2d pin.
Presumably you are using the Timer1 overflow interrupt? This method is
supposed to work by executing the next instructions. So definitely at a loss
as to why the reset.
I always use a nop after sleep to make sure the next instruction is not
executed for whatever reasons.
If you happen to be using rechargeable Li-ion, then 2.5v should be treated
as the very minimum, preferably higher (e.g. 2.8V-3.0V), otherwise risking
damage to the battery.
Glad you got a handle on it. I didn't actually realize your supply was dipping that far, lucky guess. Calls in question if your batteries are up to snuff?
You have to set up the FVR register manually to get it over to the a-d module. I like using the 2.048V setting. This is great becuase you don't have to have an external voltage reference. From a flashlight Li-ion project here is some code to get you started on your way to getting a low voltage protection for a nominal 3.7V Li-Ion battery with the warning at about 3.0V and PWM switched to low, and then put to sleep at about 2.9V? it has been awhile.
There was an empirical adjustment to the battery voltage setting due to a reverse battery protection diode.
I have tried to get some very basic battery low voltage detector going today
but seem to have had little joy and got into a muddle. There is something is
missing with my basic understanding, even though the formulas seem to make
sense.
I updated the #define FVR b'00011111' 'define FVR buffer1 output for adc to
match my 16LF1828 using the data sheet no problem.
Where I got stuck is with FixedVoltRef = AD12F1822(FVR) and
FixedVoltRef(count)) what do you mean here for the items in bold.
Also on the 16LF1828 there is a ADPREF<1:0>: A/D Positive Voltage Reference
Configuration bits which I think needs to be set to
to 11 = VREF+ is connected to internal Fixed Voltage Reference (FVR) module.
Then I was unsure how to use the A To D , as I think the gcb ReadANO gets
its reference from the supply and was unsure if the above overrode it,
then realised that I did not know where to put it into the code. I assumed
that the A TO D input was connected to VCC.
At which point it occurred to me with the A To D Ref set to the internal ref
of 2 volts any input above this will read out 255 and the BatVolt will not
change. So clearly I am missing some fundamental points somewhere.
Please could you point out where I am going wrong.
From: kent_twt4 [mailto:kent_twt4@users.sf.net]
Sent: 11 May 2015 8:58 PM
To: [gcbasic:discussion]
Subject: [gcbasic:discussion] Re: Pic 16F1828 Interrupt on change not
working at supply voltages < 3V, everything else works well.
Hey Stephen,
Glad you got a handle on it. I didn't actually realize your supply was
dipping that far, lucky guess. Calls in question if your batteries are up to
snuff?
You have to set up the FVR register manually to get it over to the a-d
module. I like using the 2.048V setting. This is great becuase you don't
have to have an external voltage reference. From a flashlight Li-ion project
here is some code to get you started on your way to getting a low voltage
protection for a nominal 3.7V Li-Ion battery with the warning at about 3.0V
and PWM switched to low, and then put to sleep at about 2.9V? it has been
awhile.
There was an empirical adjustment to the battery voltage setting due to a
reverse battery protection diode.
define FVR b'00011111' 'define FVR buffer1 output for adc
...
...
'2.048(V)/BatVolt = AD-FVR/255
'BatVolt = ((205(V) * 255)/FixedVoltRef(count)) + 26(V) (diode drop)
'promote by 100
FixedVoltRef = AD12F1822(FVR)
BatVolt = (52275/FixedVoltRef) + 30
...
...
If BatVolt <= 292 Then
CCPR1L = 0
'LowBat = 0x55
'goto BatCutOff 'Send to SwitchOff sleep routine
FVREN =0 'shut down fixed voltage reference
'TX_OUT = 0
LED = 0
WPUA4 = 0 'turn off weak pullup
asm sleep
nop
End if
If BatVolt < 300 OR ThermTempAvg > 60 Then
If CCPR1L >= 64 Then
ThrottleDown = True
CCPR1L = 13 '5 'throttle down to low at 3.0V
End if
Else
ThrottleDown = False
End if
Using code in posts requires like four tildes with space before and after like (ignore the " " quotes around the tildes):
Post content
....
....
space
"~~~~"
code here
"~~~~"
space
More content
....
....
The " define FVR b'00011111' " is a constant for the FVR adc channel select bits of the ADCON0 register. The two rotate left simple commands put the bits in their proper place of that register.
The comment of " 'define FVR buffer1 output for adc " could be expanded upon. Basically the adc is measuring what the internal FVR voltage (2.048V in my example) is, regardless of the battery voltage. The measurement is valid as long as the battery voltage is "above" the 2.048V. Have to think of this as absolute measurement, not a relative measure like a Vref+ operation, not how it works.
My bad, the Vref+ to FVR "comment" in my example is invalid. You will note however that the ADPREF bits are set to zero (VDD) in ADCON1 register, that part is correct. I will try and fix the "comment" in the post.
So the "FixedVoltRef = AD12F1822(FVR)" is going rogue, so to speak. As you have noted, GCB doesn't handle some of channel select bits, like for the DAC, FVR, and Temp Indicator. So the function was made up to handle that specifically for the 12f1822, and perhaps many other enhanced midrange devices. I was using other adc inputs too, just need to set them up with defines like in the code below, and they will work with the adc function just like GCB does (e.g. "AD12F1822(AN0)"). Name the function however you like, and use it when accessing the special adc channels.
#define AN0 0
#define AN1 1
#define AN2 2
etc.
The #define FVR is set up before Main.
The reading of the adc and conditional code was in Main.
The function code is like subs, which are after Main.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Kent
I had to leave the battery detector for a while to look at more import aspect of the project. I came back to it last week. With your updates, looking at data sheet, simplifying the code and adding some simple formulas that give resonable numbers it seems to work. I suspect the formulas may be a little too simple and out by 1 but they give good results against measured for the two devices I have tried bought at different times. Attached are results.
So if you agree I think we can consider this one closed.
I have tried to get the Internal temperature sensor working, but do not seem to be getting numbers that tie up with the microchip app note or base calculations. Have you had a joy with the temperature sensor in the past ?
Thanks for your Help
Tried a simple IOC per example with a 12f1822. Got down to 2V before going to some sort of undefined state. Granted this example is only looking for a negative going pulse, and with either the internal WPU enabled or an external 33K pullup.
While you can enable both the negative and positive going IOC with the new enhanced midrange devices, I don't see how that is going to work well without a pullup or pulldown resistor? Seems like a task for the CCP module in the capture mode, toggling between positive and negative edges in the interrupt, examples in past posts on the forum.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Your battery voltage results look great, congratulations. I am not following your simplification, the gray matter is a bit fuzzy this morning, but can't argue the results.
Tried the internal temp once and had a devil of a time trying to make sense of the result. Seems as though a massive correction factor or individual calibration was needed, and dropped it. I copped out by using a cheap mcp9700T thermistor/temp sensor :). Let us know if you get something on this.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi
I have hit a Interrupt on change problem with the pic 16F1828 that is mystifying me. I cut the code down to similar to the example in:
https://sourceforge.net/p/gcbasic/discussion/579126/thread/f4f450da/#d8bc
but am using Set IOCAP0 On : Set IOCAN0 On : Set IOCAP1 On : Set IOCAN1 On. Which should give me rise and fall detection.
In the Interrupt handler, flags IOCAF0, IOCAF1 are being cleared.
The input switching can be seen on a scope to be going between 0V and Vcc.
When the pic is running from VCC > 3.1V it works as expected However when the vcc is reduced to < 3.0 the Interrupt on change operation gets more variable until at around 2.5V the interrupts stop working.
The PIC is running on internal clock at 2Mhz. When everything else is put back in it all works down to 2.5V except for the interrupts on change. The inputs are being correctly read in.
It looks like the Interrupt on change does not work below a VCC of 2.9V very strange, but the chip spec is operation down to 1.8V.
I am clearly missing something could you point me in the right direction please.
More information needed! Is a button or switch being monitored, or is it an incoming waveform. What is the mode of operation, frequency, and purpose of the operation.
You can operate both PORTA and PORTB interrupt on change pins for the 16f1828 now? Can the bug report be closed?
Hi Kent
I had this email prepared to send but wanted to try some things out before
sending and in the meantime received your email.
As far as the bug report is concerned I suppose we should close it. It may
be worth adding something to the documentation somewhere otherwise the
question will come up again.
I not sure where in the documentation you would place the note. The first
place I looked was the help, the second the chip data for the device.
Just a thought but how about adding a simple text note in the chip data.
With reference to your question.
The device is normally in sleep it wakes up from sleep every 16 Seconds
(Timer-1 and 32kHz Crystal) or when one of the switches is changed by hand (
Interrupt on change brings out of sleep). Waits for 100mS (Timer 0) so that
any contact bounce has finished and then monitors the input Pins state (Port
A0 and Port A1). The rf device is then woken up and the input pin states are
sent out via the serial port to an rf device. Once the data has been sent
(approx 24mS) the PIC goes back to sleep. The pic in sleep is taking <
5uA.
The two switches are being operated by Hand and are simple single pole two
way switches connected to either Vcc via a 4.7k pull up or 0V. So each that
input is going either from 0V to Vcc or Vcc to 0V. The inputs also have
Schottky diode input protection, the wire length to the switches is approx
3".
The purpose of the interrupt on change is just to wake the device up from
sleep. The switches are operated by hand not machine so the max frequency of
operation will be around 50-100mS. I am switching them every few seconds.
At VCC between 2.5V and 3.6V the switches are always correctly read when the
device wakes up from sleep every 16 Secs (This will be changed to hours
latter)
At vcc =3.3V everything works fine, The packets arrive correctly with the
correct numbers in them as the switches are changed.
At vcc of 2.5V the device wakes up when the switches are activated but the
data is filled 0 or sometimes the correct data is displayed and the it
changes back to 0.
A couple of things I have noticed today, an LED indicator added shows that
when the switches are activated it always comes out of sleep which is good.
The other thing I have noticed is an interaction with timer 0. If I disable
the de-bounce code it seems to work reliably down to 2.5V. I have been
looking at it on and off all day
but cannot pin-point the issue. Perhaps there is a bug in my code somewhere.
I cannot make the mental connection between the problem and why it would be
supply dependant in a digital system.
For your information I am knocking down the voltage using the PicKit 2 S/W.
2.5V is the lowest it goes. I have a swictch that disconnects the inputs
from the pic programmer so that the pic-kit 2 does not pull down the inputs.
I will have another look tomorrow.
Hope I have answered you questions.
Thanks for the help.
From: kent_twt4 [mailto:kent_twt4@users.sf.net]
Sent: 19 April 2015 12:07 AM
To: [gcbasic:discussion]
Subject: [gcbasic:discussion] Pic 16F1828 Interrupt on change not working at
supply voltages < 3V, everything else works well.
More information needed! Is a button or switch being monitored, or is it an
incoming waveform. What is the mode of operation, frequency, and purpose of
the operation.
You can operate both PORTA and PORTB interrupt on change pins for the
16f1828 now? Can the bug report be closed?
Pic 16F1828 Interrupt on change not working at supply voltages
https://sourceforge.net/p/gcbasic/discussion/579126/thread/2dc5e5b5/?limit= 25#0b28 < 3V, everything else works well.
Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/gcbasic/discussion/579126/
https://sourceforge.net/p/gcbasic/discussion/579126
To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/
https://sourceforge.net/auth/subscriptions
@Stephen: A few of things I can think of:
1) Can switch operation be converted over to a momentary pushbutton, or just use the switch in a negative going pulse? This would be single ended operation and clean up my doubts about having the negative and positive IOC at the same time.
2) Try mechanical debouncing with a 0.1uf (Or?) cap, and ditch the software debouncing?
2) If the schottky diode is inline then you could be losing .5V to .7V on the switch signal, leaving it an unreliable voltage zone? Wouldn't think you would need it?
3) I know from using a ttl UART converter at sub 3V voltage levels, that signal integrity, or the signal voltage can lead to failed transmissions. So from that standpoint, check the RF data sheet to see the minimum high level voltage you can work with.
4) Extra supply bypass capacitance? RF devices can be power hogs, so add an extra 47uf, 100uf cap?
Hello Kent
Thanks for the tips
After many hours the problem seems to be traced to the BOREN.
With BOREN On or Off it all works down to VCC OF 2.55V. (I still have the
100uf capacitor on vcc as a precaution, not that it made any difference)
With BOREN set to BOREN=NSLEEP I see issues. What seems to be happening is
the code is breaking out of the main program and starting at the first line,
I suspect this is a device reset.
I have tried BORV = 1 '1=1.9V, 0=2.5v Typical. Which made no difference in
BOREN=NSLEEP.
I have also tried waiting for BORRDY=1 'which also made no difference.
So as BOREN On use a lot of current I am tempted just to switch it off.
I am not to sure what the implications are, this is a battery operated
board, the rf will pack up at ~2V anyway and the battery will be near end
of life at 2- 2.5V. So I am tempted to call it a day on this problem and
move on.
Have you come across BOREN NSLEEP issues before. This is an area I have no
experience in.
Thanks
Steve
From: kent_twt4 [mailto:kent_twt4@users.sf.net]
Sent: 20 April 2015 1:01 AM
To: [gcbasic:discussion]
Subject: [gcbasic:discussion] Re: Pic 16F1828 Interrupt on change not
working at supply voltages < 3V, everything else works well.
@Stephen: A few of things I can think of:
1) Can switch operation be converted over to a momentary pushbutton, or just
use the switch in a negative going pulse? This would be single ended
operation and clean up my doubts about having the negative and positive IOC
at the same time.
2) Try mechanical debouncing with a 0.1uf (Or?) cap, and ditch the software
debouncing?
2) If the schottky diode is inline then you could be losing .5V to .7V on
the switch signal, leaving it an unreliable voltage zone? Wouldn't think you
would need it?
3) I know from using a ttl UART converter at sub 3V voltage levels, that
signal integrity, or the signal voltage can lead to failed transmissions. So
from that standpoint, check the RF data sheet to see the minimum high level
voltage you can work with.
4) Extra supply bypass capacitance? RF devices can be power hogs, so add an
extra 47uf, 100uf cap?
Pic 16F1828 Interrupt on change not working at supply voltages
https://sourceforge.net/p/gcbasic/discussion/579126/thread/2dc5e5b5/?limit= 25#0b28/1def/235e < 3V, everything else works well.
Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/gcbasic/discussion/579126/
https://sourceforge.net/p/gcbasic/discussion/579126
To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/
https://sourceforge.net/auth/subscriptions
The BOREN config bits should not really have a bearing on causing a device to reset from sleep. Using the INT pin as an interrupt from sleep it always continues on from where it left off (i.e. no reset), regardless if BOREN is ON, OFF, or NSLEEP. I would leave it off and monitor the battery voltage with an a2d pin.
Presumably you are using the Timer1 overflow interrupt? This method is supposed to work by executing the next instructions. So definitely at a loss as to why the reset.
I always use a nop after sleep to make sure the next instruction is not executed for whatever reasons.
If you happen to be using rechargeable Li-ion, then 2.5v should be treated as the very minimum, preferably higher (e.g. 2.8V-3.0V), otherwise risking damage to the battery.
Hi Kent
First Thanks for your help, knowing some has made it work and who has good
ideas of things to look at is a big help.
I implemented a S/W BOREN and traced down the issue to the RF module
switching on and off (as you suspected). The monster capacitor helps, but is
not the solution and is not practical for me. Looking at the battery data
sheet it has a series resistance of 6.3 ohms at 30mA which leads to a change
in supply rail just enough to trigger the Brown out detector even with a
fair bit of decoupling. The voltage change and response do not look that bad
so I cannot say for sure if it is the level or rate of change or both that
are doing the damage.
With a 3.6V battery having a series R of 6.3 ohms at 30mA together with
temperature and aging I have come to the conclusion that the BOR is just not
suitable for low voltage battery apps and have switched it off.
The unit is working nicely down to 2.2V which give me enough headroom for a
3.6V Battery. Current consumption is 3uA (Sleep) to 30mA (TX).
In the past couple of days I have come across a microchip app note that says
BOR is not recommended for battery application.
I hope this helps the next person who comes across this type of problem.
You suggested to use an A To D to generate a low voltage Alarm, but I think
this requires using the internal voltage reference and the GC ADFormat does
not have this option, I had a look at the include file but it looks a bit
beyond me at the moment. Have you come across a good example that I can use
as a starting point.
Thanks again.
From: kent_twt4 [mailto:kent_twt4@users.sf.net]
Sent: 24 April 2015 2:05 AM
To: [gcbasic:discussion]
Subject: [gcbasic:discussion] Re: Pic 16F1828 Interrupt on change not
working at supply voltages < 3V, everything else works well.
The BOREN config bits should not really have a bearing on causing a device
to reset from sleep. Using the INT pin as an interrupt from sleep it always
continues on from where it left off (i.e. no reset), regardless if BOREN is
ON, OFF, or NSLEEP. I would leave it off and monitor the battery voltage
with an a2d pin.
Presumably you are using the Timer1 overflow interrupt? This method is
supposed to work by executing the next instructions. So definitely at a loss
as to why the reset.
I always use a nop after sleep to make sure the next instruction is not
executed for whatever reasons.
If you happen to be using rechargeable Li-ion, then 2.5v should be treated
as the very minimum, preferably higher (e.g. 2.8V-3.0V), otherwise risking
damage to the battery.
Pic 16F1828 Interrupt on change not working at supply voltages
https://sourceforge.net/p/gcbasic/discussion/579126/thread/2dc5e5b5/?limit= 25#0b28/1def/235e/3cdf/ccfd < 3V, everything else works well.
Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/gcbasic/discussion/579126/
https://sourceforge.net/p/gcbasic/discussion/579126
To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/
https://sourceforge.net/auth/subscriptions
Hey Stephen,
Glad you got a handle on it. I didn't actually realize your supply was dipping that far, lucky guess. Calls in question if your batteries are up to snuff?
You have to set up the FVR register manually to get it over to the a-d module. I like using the 2.048V setting. This is great becuase you don't have to have an external voltage reference. From a flashlight Li-ion project here is some code to get you started on your way to getting a low voltage protection for a nominal 3.7V Li-Ion battery with the warning at about 3.0V and PWM switched to low, and then put to sleep at about 2.9V? it has been awhile.
There was an empirical adjustment to the battery voltage setting due to a reverse battery protection diode.
EDIT: Oops! forgot to add the custom a-d function.
Last edit: kent_twt4 2015-05-11
Hi Kent
I have tried to get some very basic battery low voltage detector going today
but seem to have had little joy and got into a muddle. There is something is
missing with my basic understanding, even though the formulas seem to make
sense.
I updated the #define FVR b'00011111' 'define FVR buffer1 output for adc to
match my 16LF1828 using the data sheet no problem.
Where I got stuck is with FixedVoltRef = AD12F1822(FVR) and
FixedVoltRef(count)) what do you mean here for the items in bold.
Also on the 16LF1828 there is a ADPREF<1:0>: A/D Positive Voltage Reference
Configuration bits which I think needs to be set to
to 11 = VREF+ is connected to internal Fixed Voltage Reference (FVR) module.
Then I was unsure how to use the A To D , as I think the gcb ReadANO gets
its reference from the supply and was unsure if the above overrode it,
then realised that I did not know where to put it into the code. I assumed
that the A TO D input was connected to VCC.
At which point it occurred to me with the A To D Ref set to the internal ref
of 2 volts any input above this will read out 255 and the BatVolt will not
change. So clearly I am missing some fundamental points somewhere.
Please could you point out where I am going wrong.
From: kent_twt4 [mailto:kent_twt4@users.sf.net]
Sent: 11 May 2015 8:58 PM
To: [gcbasic:discussion]
Subject: [gcbasic:discussion] Re: Pic 16F1828 Interrupt on change not
working at supply voltages < 3V, everything else works well.
Hey Stephen,
Glad you got a handle on it. I didn't actually realize your supply was
dipping that far, lucky guess. Calls in question if your batteries are up to
snuff?
You have to set up the FVR register manually to get it over to the a-d
module. I like using the 2.048V setting. This is great becuase you don't
have to have an external voltage reference. From a flashlight Li-ion project
here is some code to get you started on your way to getting a low voltage
protection for a nominal 3.7V Li-Ion battery with the warning at about 3.0V
and PWM switched to low, and then put to sleep at about 2.9V? it has been
awhile.
There was an empirical adjustment to the battery voltage setting due to a
reverse battery protection diode.
define FVR b'00011111' 'define FVR buffer1 output for adc
...
...
'2.048(V)/BatVolt = AD-FVR/255
'BatVolt = ((205(V) * 255)/FixedVoltRef(count)) + 26(V) (diode drop)
'promote by 100
FixedVoltRef = AD12F1822(FVR)
BatVolt = (52275/FixedVoltRef) + 30
...
...
If BatVolt <= 292 Then
CCPR1L = 0
'LowBat = 0x55
'goto BatCutOff 'Send to SwitchOff sleep routine
FVREN =0 'shut down fixed voltage reference
'TX_OUT = 0
LED = 0
WPUA4 = 0 'turn off weak pullup
asm sleep
nop
End if
If BatVolt < 300 OR ThermTempAvg > 60 Then
If CCPR1L >= 64 Then
ThrottleDown = True
CCPR1L = 13 '5 'throttle down to low at 3.0V
End if
Else
ThrottleDown = False
End if
Pic 16F1828 Interrupt on change not working at supply voltages
https://sourceforge.net/p/gcbasic/discussion/579126/thread/2dc5e5b5/?limit= 25#0b28/1def/235e/3cdf/ccfd/82f9/cb81 < 3V, everything else works well.
Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/gcbasic/discussion/579126/
https://sourceforge.net/p/gcbasic/discussion/579126
To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/
https://sourceforge.net/auth/subscriptions
Using code in posts requires like four tildes with space before and after like (ignore the " " quotes around the tildes):
The " define FVR b'00011111' " is a constant for the FVR adc channel select bits of the ADCON0 register. The two rotate left simple commands put the bits in their proper place of that register.
The comment of " 'define FVR buffer1 output for adc " could be expanded upon. Basically the adc is measuring what the internal FVR voltage (2.048V in my example) is, regardless of the battery voltage. The measurement is valid as long as the battery voltage is "above" the 2.048V. Have to think of this as absolute measurement, not a relative measure like a Vref+ operation, not how it works.
My bad, the Vref+ to FVR "comment" in my example is invalid. You will note however that the ADPREF bits are set to zero (VDD) in ADCON1 register, that part is correct. I will try and fix the "comment" in the post.
So the "FixedVoltRef = AD12F1822(FVR)" is going rogue, so to speak. As you have noted, GCB doesn't handle some of channel select bits, like for the DAC, FVR, and Temp Indicator. So the function was made up to handle that specifically for the 12f1822, and perhaps many other enhanced midrange devices. I was using other adc inputs too, just need to set them up with defines like in the code below, and they will work with the adc function just like GCB does (e.g. "AD12F1822(AN0)"). Name the function however you like, and use it when accessing the special adc channels.
The #define FVR is set up before Main.
The reading of the adc and conditional code was in Main.
The function code is like subs, which are after Main.
Hi Kent
I had to leave the battery detector for a while to look at more import aspect of the project. I came back to it last week. With your updates, looking at data sheet, simplifying the code and adding some simple formulas that give resonable numbers it seems to work. I suspect the formulas may be a little too simple and out by 1 but they give good results against measured for the two devices I have tried bought at different times. Attached are results.
So if you agree I think we can consider this one closed.
I have tried to get the Internal temperature sensor working, but do not seem to be getting numbers that tie up with the microchip app note or base calculations. Have you had a joy with the temperature sensor in the past ?
Thanks for your Help
Tried a simple IOC per example with a 12f1822. Got down to 2V before going to some sort of undefined state. Granted this example is only looking for a negative going pulse, and with either the internal WPU enabled or an external 33K pullup.
While you can enable both the negative and positive going IOC with the new enhanced midrange devices, I don't see how that is going to work well without a pullup or pulldown resistor? Seems like a task for the CCP module in the capture mode, toggling between positive and negative edges in the interrupt, examples in past posts on the forum.
Your battery voltage results look great, congratulations. I am not following your simplification, the gray matter is a bit fuzzy this morning, but can't argue the results.
Tried the internal temp once and had a devil of a time trying to make sense of the result. Seems as though a massive correction factor or individual calibration was needed, and dropped it. I copped out by using a cheap mcp9700T thermistor/temp sensor :). Let us know if you get something on this.