| View previous topic :: View next topic |
| Author |
Message |
Alphada
Joined: 19 Jun 2017
Posts: 27
|
| IOC interrupt not working PIC16F1786 |
 Posted: Sat Jul 08, 2017 3:37 pm |
 |
|
Compiler Version 5.070
I'm trying to understand how does the IOC works but the interrupt wont fire.
This is my code
| Code: | #include <main.h>
#INT_IOC
void IOC_isr(void)
{
printf("IOC");
}
void main()
{
setup_oscillator(OSC_1MHZ | OSC_INTRC);
set_tris_a(0x0F); //A0 A1 A2 A3 as input
enable_interrupts(INT_IOC_A0);
enable_interrupts(INT_IOC_A1);
enable_interrupts(INT_IOC_A2);
enable_interrupts(INT_IOC_A3);
enable_interrupts(GLOBAL);
printf("TESTING",);
while(TRUE)
{
}
} |
My interface
When i use:
| Code: | | enable_interrupts(INT_IOC); |
it does fire but does a feedback with the Rx pin changes and it loops forever every time i try to post on the console.
Am i doing something wrong or is just a bug?
Thx in advance!!!! |
|
 |
dyeatman
Joined: 06 Sep 2003
Posts: 1933
Location: Norman, OK
|
|
| Posted: Sat Jul 08, 2017 4:25 pm |
|
|
When the IOC interrupt fires you must read the port in the interrupt routine to reset the interrupt.
_________________
Google and Forum Search are some of your best tools!!!! |
|
|
Alphada
Joined: 19 Jun 2017
Posts: 27
|
|
| Posted: Sat Jul 08, 2017 4:30 pm |
|
|
| dyeatman wrote: | | When the IOC interrupt fires you must read the port in the interrupt routine to reset the interrupt. |
that's something I notice some how, but it doesn't even fire one time it just doesn't, how should I initialize those values or registers to make it work :/ |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9225
Location: Greensville,Ontario
|
|
| Posted: Sat Jul 08, 2017 6:23 pm |
|
|
The program you show us is NOT complete and I seriously doubt it will compile.
Your schematic has several errors and omissions so I conclude you're 'testing' using Proteus ? If so be advised that Proteus itself is faulty and will NOT simulate a PIC properly. |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Sat Jul 08, 2017 6:42 pm |
|
|
Here are 3 threads on using IOC interrupts with the 16F17xx series PICs:
PIC16F1769 Interrupt problem:
http://www.ccsinfo.com/forum/viewtopic.php?t=54775
16F1783 IOC Interrupt Initialization Problems
http://www.ccsinfo.com/forum/viewtopic.php?t=54075
Interruption loops ... despite flag clear:
http://www.ccsinfo.com/forum/viewtopic.php?t=55474
In the thread above, his compiler apparently has a bug in the
interrupt vectoring. He describes his fix. His compiler version is 5.043.
You have vs. 5.070, so hopefully the bug is fixed by now.
Also, your pushbuttons are wrong. They leave the IOC pins floating
or at +5v. This will not work. The IOC pins must be kept at defined
logic levels. This means a high or a low level, not floating.
Use the following circuit on each pin:
| Code: | +5v
|
<
> 4.7K
< ___ Switch
To | _|_|_
PIC -----------------o o------
IOC pin |
--- GND
- |
|
|
|
Alphada
Joined: 19 Jun 2017
Posts: 27
|
|
| Posted: Sat Jul 08, 2017 7:50 pm |
|
|
| temtronic wrote: | The program you show us is NOT complete and I seriously doubt it will compile.
Your schematic has several errors and omissions so I conclude you're 'testing' using Proteus ? If so be advised that Proteus itself is faulty and will NOT simulate a PIC properly. |
like? would you point the "omissions" so it can be fixed? |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9225
Location: Greensville,Ontario
|
|
| Posted: Sat Jul 08, 2017 8:12 pm |
|
|
some hardware errors from the schematic include
no ground(VSS) to PIC
no power (VDD) to PIC
no power supply bypass caps
no pullup on MCLR
all I/O pins not terminated
no filter caps on PB switch/Input pin(IE NO HW debounce)
some software errors from the program include
use of printf() inside an interrupt
no declaration of USE RS232(.....) hint ...baudrate...
no picdevice header ( must be 1st line of code)..
last one MUST be there to compile
2nd last one if not there should generate a fatal error
1st one will impact performance |
|
|
Alphada
Joined: 19 Jun 2017
Posts: 27
|
|
| Posted: Sat Jul 08, 2017 8:34 pm |
|
|
| PCM programmer wrote: |
Also, your pushbuttons are wrong. They leave the IOC pins floating
or at +5v. This will not work. The IOC pins must be kept at defined
logic levels. This means a high or a low level, not floating.
Use the following circuit on each pin:
| Code: | +5v
|
<
> 4.7K
< ___ Switch
To | _|_|_
PIC -----------------o o------
IOC pin |
--- GND
- |
|
Thx for your answer, you were right that was the problem, after initializing these pins with:
| Code: | output_low(pin_A0);
output_low(pin_A1);
output_low(pin_A2);
output_low(pin_A3) |
it works fine, thanks again for the enlightenment. there was a misconception by my part on how the pins logic states work, thought this was enough:
| Code: | | set_tris_a(0x0F); //A0 A1 A2 A3 as input |
but i was wrong. |
|
|
newguy
Joined: 24 Jun 2004
Posts: 1907
|
|
| Posted: Sat Jul 08, 2017 8:46 pm |
|
|
| Alphada wrote: | Thx for your answer, you were right that was the problem, after initializing these pins with:
| Code: | output_low(pin_A0);
output_low(pin_A1);
output_low(pin_A2);
output_low(pin_A3) |
it works fine, thanks again for the enlightenment. there was a misconception by my part on how the pins logic states work, tought this was enough:
|
Driving those pins low (I'm assuming you're not using #fast_io) just means that you're having the PIC "fight" a short circuit to Vcc when a button is pressed. Not a recipe for longevity with regards to your design. |
|
|
Alphada
Joined: 19 Jun 2017
Posts: 27
|
|
| Posted: Sun Jul 09, 2017 1:41 pm |
|
|
| newguy wrote: | | Alphada wrote: | Thx for your answer, you were right that was the problem, after initializing these pins with:
| Code: | output_low(pin_A0);
output_low(pin_A1);
output_low(pin_A2);
output_low(pin_A3) |
it works fine, thanks again for the enlightenment. there was a misconception by my part on how the pins logic states work, tought this was enough:
|
Driving those pins low (I'm assuming you're not using #fast_io) just means that you're having the PIC "fight" a short circuit to Vcc when a button is pressed. Not a recipe for longevity with regards to your design. |
excuse me I have no idea of what I am doing lol  , what would be the right way?
Last edited by Alphada on Sun Jul 09, 2017 1:53 pm; edited 1 time in total |
|
|
Alphada
Joined: 19 Jun 2017
Posts: 27
|
|
| Posted: Sun Jul 09, 2017 1:50 pm |
|
|
| temtronic wrote: | some hardware errors from the schematic include
no ground(VSS) to PIC
no power (VDD) to PIC
no power supply bypass caps
no pullup on MCLR
all I/O pins not terminated
no filter caps on PB switch/Input pin(IE NO HW debounce)
some software errors from the program include
use of printf() inside an interrupt
no declaration of USE RS232(.....) hint ...baudrate...
no picdevice header ( must be 1st line of code)..
last one MUST be there to compile
2nd last one if not there should generate a fatal error
1st one will impact performance |
The use of printf shouldn't be used on the interrupt, i know that. but i just want to test.
No ground(VSS) to PIC
No power (VDD) to PIC
They are not necessary when simulating in Proteus.
The declaration of
USE RS232(.....) and no pic device is in the main.h (as does by default CCS when using wizard).
Now my doubts:
No pullup on MCLR. Do i still need it when using the fuse NOMCLR? which is in the main.h too.
Do I still need a bypass cap when running on battery?
I was planing to implement soft debounce, but now you mention which would be the advantage of using hw debounce?
What does this mean: all I/O pins not terminated |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19506
|
|
| Posted: Sun Jul 09, 2017 2:26 pm |
|
|
On the smoothing. YES.
Whatever your source, there is always the problem that internally, the chip _will_ draw momentary massively different power levels at nSec timings. This _will_ generate instantaneous tiny ripples on the supply rail at the chip just from the wiring impedance, and the impedance of the source. It is these ripples that the decoupling _immediately adjacent to the PIC_ is needed to handle.
On hardware debounce, this is particularly necessary when using interrupt driven handling. Problem otherwise is that the chip can end up becoming 'deadlocked' handling repeated interrupt events. Some types of key are guaranteed to generate 'clean' switching, but most are not.
The MCLR line should connect to something. It is particularly sensitive to any induced noise taking it above Vdd (no protection diode). This can cause erratic operation. So just having it floating can be dangerous.
Any I/O pin you are not using, should either have a connection like a resistor to a supply rail, or be programmed to be an output.
Proteus makes the supply connections invisibly. It's a 'feature', that can be dangerous, but it's part of Proteus.
The Proteus simulator will accept what you tell it about clocks, the real chip is not this forgiving. This is why it is always worth testing that a chip really is working, and at the speed you think it is.
If posting code, you should include what is in the 'main.h', since it is very easy to have settings here that don't let the chip work. The Wizard is totally thick, and will allow settings that can't work.... |
|
|
Alphada
Joined: 19 Jun 2017
Posts: 27
|
|
| Posted: Sun Jul 09, 2017 3:00 pm |
|
|
| Ttelmah wrote: | On the smoothing. YES.
Whatever your source, there is always the problem that internally, the chip _will_ draw momentary massively different power levels at nSec timings. This _will_ generate instantaneous tiny ripples on the supply rail at the chip just from the wiring impedance, and the impedance of the source. It is these ripples that the decoupling _immediately adjacent to the PIC_ is needed to handle.
On hardware debounce, this is particularly necessary when using interrupt driven handling. Problem otherwise is that the chip can end up becoming 'deadlocked' handling repeated interrupt events. Some types of key are guaranteed to generate 'clean' switching, but most are not.
The MCLR line should connect to something. It is particularly sensitive to any induced noise taking it above Vdd (no protection diode). This can cause erratic operation. So just having it floating can be dangerous.
Any I/O pin you are not using, should either have a connection like a resistor to a supply rail, or be programmed to be an output.
Proteus makes the supply connections invisibly. It's a 'feature', that can be dangerous, but it's part of Proteus.
The Proteus simulator will accept what you tell it about clocks, the real chip is not this forgiving. This is why it is always worth testing that a chip really is working, and at the speed you think it is.
If posting code, you should include what is in the 'main.h', since it is very easy to have settings here that don't let the chip work. The Wizard is totally thick, and will allow settings that can't work.... |
This clarifies a lot for real.
I have a board to test it in real life but Proteus is just the way i have to do rapid tests once its working there I move to the board. I been told a lot to not trust in Proteus and i have found my self in situations where it works in Proteus but it fails on the chip. but still a useful tool. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9225
Location: Greensville,Ontario
|
|
| Posted: Sun Jul 09, 2017 3:20 pm |
|
|
One of the problems with Proteus is the schematic doesn't show power connections so if you give a student just the schematic and say 'make it in hardware', it'll never work. A schematic is like a blueprint, what you see it what gets built. Had a professor who insisted that a power switch was necessary in every drawing, again to reflect the Real World. Getting docked 20 points from 30 for not having it was a painful lesson but after 40 years I still remember it and to draw on/off switches !
As pointed out all PIC pins need to go 'somewhere'. If left 'floating in the breeze', they become miniature antennas and can pickup 'noise', EMI, etc. and then things really become hard to troubleshoot!!
Jay |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
