Interrupt mystery - need some guru help

[xnihilo]

In the code below, something strange happens.
(I'm using an LCD display to check what's happening in the program.)

When the program starts, it seems to jump directly to the On Interrupt routine and when the porta pins states are displayed I see that the values are those I expect:
A.0=1, A.1=1, A.2=1, A.3=0, A.4=1, A.5=1 so no interrupt should have occured because there is absolutely nothing connected to portA.

WHY???

Can someone help me to solve this mystery.

Thanks for any help.














@ device pic16F684, intrc_osc_noclkout, BOD_OFF, PWRT_OFF, wdt_off, mclr_off, protect_off

DEFINE OSC 8 'set OSC value to 8MHz for instructions PAUSE, PAUSEus and SOUND

'-----------------------------------------
DEFINE LCD_DREG PORTC 'data port out is portc
DEFINE LCD_DBIT 0 'data on portc0-portc3

DEFINE LCD_RSREG PORTC 'rs is on portC5
DEFINE LCD_RSBIT 5

DEFINE LCD_EREG PORTC 'enable in on portC4
DEFINE LCD_EBIT 4

DEFINE LCD_BITS 4 '4bits data bus
DEFINE LCD_LINES 2 '2lines display
DEFINE LCD_COMMANDUS 2000 '2ms cmd delay
DEFINE LCD_DATAUS 50 '50us data delay

CLEAR

OSCCON = %01110001
CMCON0 = %00000111 'comparators OFF, val = 7
ANSEL = %00000000 'choose digital i/o, val = 0
OPTION_REG = %01111111 'enable porta weak pullups (no weak pull-up available for porta.3), p12
WPUA = %110111 'enable internal weak pull ups resistors individually on portA pins to bring them HIGH internaly, except for porta.3 (Ra3 can be set as mclr or as i/o port with config words)
INTCON = %10001000 'enable GIE and porta interrupts on change, datasheet p13
IOCA = %111111 'no int for ra4 = r/s bit
TRISA = %111111
TRISC = %000000 'all portc pins are set to output mode, PWM starts if CCP1CON is enabled
'PORTA = %000000 'turn off porta pins
'PORTC = %000000 'turn off portc pins

i VAR BYTE

ON INTERRUPT GOTO in_sig 'when interrupt occurs on any portA pin (except portA.3) go to int routine

loop1: 'main program is a stupid loop waiting for a int on change triggered by an ir signal on sensors

'-----------------
'test
lcdout $fe,2 'home pos
lcdout $fe,1,"loop1" 'clear and display
'-----------------

PAUSEus 15 'shortest pause possible to quickly jump to routine for extracting bullet signal contents
'at 8MHz, minimum delay is 12 uS (or 24 uS at 4MHz)
'in my routine, some uS can be wasted until the signal decoding occurs, too much and the signal will be invalid because of the offset
GOTO loop1

DISABLE
'disable interrupts while executing the interrupt routine (do not put check interrupts calls after each instruction)
in_sig: 'int routine code starts here
'--------------
for i = 0 to 5
LCDOUT $FE, 1,"value",#i,"=",#portA.0(i)
PAUSE 2000
nEXT i

INTCON.0 = 0

resume 'end int routine
enable 'REENABLE interrupts (global flag), PBP lame instruction

END 'end of program

'1. How can I reference a BIT in a BYTE?
'http://www.picbasic.co.uk/forum/archive/index.php/t-544.html
' For MyVar=0 to 7
'MyBit=MyByte.0(MyVar)
'LCDOut $FE,1,"Bit ",#MyVar,"=",#MyBit
'Pause 2000
'Next MyVar

[skimask]

No mystery here...
Re-read the IOC section in the datasheet...
Your answer is there...

[xnihilo]

yes, there are a lot of answers there.
I'm not a programmer so it requires a lot of efforts for me to program. I'm new with PBP and PICs.
It's pretty complicated and I'm tired because I work on my project every night till late so I must be missing the point. So if you know the answer, could you help me please.

[skimask]

I'm not a programmer so it requires a lot of efforts for me to program. I'm new with PBP and PICs.
It's pretty complicated and I'm tired because I work on my project every night till late so I must be missing the point. So if you know the answer, could you help me please.
I'm not a programmer either...just ask anybody around here!
But you're answer really is in the datasheet, DS41202F, Section 4.2.3
And if I tell you, then you will have learned but ONE single thing.
If you figure it out, you'll have begun to understand a number of things...

[xnihilo]

is it because pic sets all ports to input pins upon powerup?

[BobP]

Hi xnihilo,

skimask has pinpointed the passage in the datasheet that clearly tells you what you need to do before enabling the interrupt and after servicing the interrupt. I appreciate that English is probably not your first language but re-examine the paragraph and what it tells you is required before enabling the interrupt?

Regards,
Bob

[xnihilo]

Please, no more riddles.

I beleive the portA has to be read prior to enabling interrupts.


Are these steps order right?

- enable weak pullups with OPTION_REG = %01111111 (even if I DON'T know what should be the settings for bits 0 to 6, which seem not useful for me)
- enable WPU for desired ports, for me it should be: 010111 (no WPU for RA3 which is used as an input port) (no WPU for RA5 which is used with default 0V and is activated when 5V gets to this pin)
- TRISA = %101111 because all porta pins has to be input except for pin RA4 which is used for R/S bit for an LCD pannel
- TRISC = %000000 (all output)
- PORTA.5 = 0 (I set specificaly RA5 to 0 because I want it to be LOW at the start, all other porta pins will be brought high automatically by WPU)
- PORTC = %000000 (I set all portC pins low)
- I initialize all my variables
- I put some stuff here like display on LCD
- IOCA = %101111 because I enable PORTA change interrupt for all porta pins except for the pin used for LCD R/S bit
- INTCON = %10001000 (I enable interrupts: GIE and portachange)
- ON INTERRUPT GOTO myroutine

Is that correct?

[skimask]

Please, no more riddles.
There's only one riddle...why haven't you read the section I specified earlier?
It's right there in the datasheet...Section 4.2.3, 2nd paragraph.

[xnihilo]

There's only one riddle...why haven't you read the section I specified earlier?
It's right there in the datasheet...Section 4.2.3, 2nd paragraph.

I did.
Never mind, I will ask in another forum.

I think the problem comes from the fact that my RA3 is linked to nothing. I will connect it to 5V via a 10K resistor.

[skimask]

Never mind, I will ask in another forum.
I think the problem comes from the fact that my RA3 is linked to nothing. I will connect it to 5V via a 10K resistor.
Hey, I'm just trying to help you learn how to read a datasheet...or at least read between the lines in a datasheet. Some of the information is a bit subtle.
And yes, it's a distinct possibility that a floating input could be triggering something it shouldn't.

[mbruno]

Re-Read the replys the Clue to solve your mystery is "I.O.C."...
hopes this helps just a little

[BobP]

Hi xnihilo,

Don't get upset! We are only trying to help.

A lot of posts the user just wants the answer without learning the ways of Microchip and the PIC's. They learn how to solve that problem but not how to understand the datasheet.
Don't get me wrong, I have spent hours pulling out my hair and after posting the problem it turns out to be a simple mistake that I have made. We are all human.

The important part of the datasheet is this bit,

'For enabled interrupt-on-change pins, the values are
compared with the old value latched on the last read of
PORTA. The ‘mismatch’ outputs of the last read are
OR’d together to set the PORTA Change Interrupt Flag
bit (RAIF) in the INTCON register (Register 2-3).'

The following tip is the last I can give. The next step is to write the program for you!

Read the port before enabling the interupt!!!

Regards,
Bob

[mbruno]

A little more help. remember if any pins change state the RAIF is set in the INTCON register, you must end any mismatch on the port first then reset the RAIF bit. Can't be much more clear than this

Mike

[xnihilo]

Hi xnihilo,

Don't get upset! We are only trying to help.

A lot of posts the user just wants the answer without learning the ways of Microchip and the PIC's. They learn how to solve that problem but not how to understand the datasheet.
Don't get me wrong, I have spent hours pulling out my hair and after posting the problem it turns out to be a simple mistake that I have made. We are all human.

The important part of the datasheet is this bit,

'For enabled interrupt-on-change pins, the values are
compared with the old value latched on the last read of
PORTA. The ‘mismatch’ outputs of the last read are
OR’d together to set the PORTA Change Interrupt Flag
bit (RAIF) in the INTCON register (Register 2-3).'

The following tip is the last I can give. The next step is to write the program for you!

Read the port before enabling the interupt!!!

Regards,
Bob

Come on! I know i sound stupid but i am not.
i DO read porta bits individually prior to enabling intcon, even if i maybe didn't mention it.
the int occurs anyway. when i outout the state of porta at the begining of interrupt routine 2 strange things can be noticed. it seems it is ra3 that triggers the interrupt. however i used the same program structure for another project and i didn'have such problem. even if the ra3 was left floating.
second thing: porta.5 value is not what it is supposed to be. with no wpu and set low with trisa, it is high when interrupt occurs. dammit.

the complete source code is at:
http://users.edpnet.be/charlesetchristelle/squadtag/se210308.pbp

[Acetronics2]

Hi,

I do hate war games ... ( except the film ...) BUT




FOR i = 0 to 5
aport[i] = porta.0(i) 'mirror the pins states into the array
NEXT i



Are you really sure of those lines ... ???



Alain

PS


IF dead == 1 THEN finish 'if player is already dead, don't answer and leave the int routine



Ha,ha,ha ... YOU 're dead !!!

Re-PS



The PICs control transistors that drive relays for 9V supply to nichrome wires for the physical feedback.
One cm of 38ga Nichrome wire, with 9V and a 6 ohms resistor is heated for 500ms, inducing a little burn that will leave a very tiny scar similar to cat's claw scratch.


And overall sado-maso games ...

WHAT A PITY !!!

[mbruno]

Question are you reading porta.0 five times or porta.0,1,2,3,4,5
just a question on interpation of you code

MIke

[xnihilo]

Question are you reading porta.0 five times or porta.0,1,2,3,4,5
just a question on interpation of you code

MIke

this syntax allows me to read porta bits starting from bit0, not documented in pbp pro manual but explain in a forum and tested succesfuly. this is a way to access port bits with an index.

[Acetronics2]

this syntax allows me to read porta bits starting from bit0, not documented in pbp pro manual .

FALSE :

Last manual

$5.66 ...

Once more dead ...

Alain

GAME OVER ... tadaaaaaa !

[xnihilo]

Hi,

I do hate war games ... ( except the film ...) BUT




FOR i = 0 to 5
aport[i] = porta.0(i) 'mirror the pins states into the array
NEXT i



Are you really sure of those lines ... ???

Yes. You can try it.



Alain

PS


IF dead == 1 THEN finish 'if player is already dead, don't answer and leave the int routine



Ha,ha,ha ... YOU 're dead !!!


What do you mean?


Re-PS



The PICs control transistors that drive relays for 9V supply to nichrome wires for the physical feedback.
One cm of 38ga Nichrome wire, with 9V and a 6 ohms resistor is heated for 500ms, inducing a little burn that will leave a very tiny scar similar to cat's claw scratch.


And overall sado-maso games ...

WHAT A PITY !!!

It is a lasergame with physical feedback an recoil.

[xnihilo]

FALSE :

Last manual

$5.66 ...

Once more dead ...

Alain

GAME OVER ... tadaaaaaa !

If you know it is the right syntax, then
why do you ask?
Maybe i should get the latest manual.

[Acetronics2]

Yes. You can try it.

>>> NO !!! Won't work ...



What do you mean?

>>> I leave your routine where it is ...


It is a lasergame with physical feedback an recoil.

>>> Sado-Maso's little chicken warrior's game : Try it with real ammunition and real ennemies , you won't be so proud ...

Alain

[skimask]

The important part of the datasheet is this bit,
'For enabled interrupt-on-change pins, the values are
compared with the old value latched on the last read of
PORTA. The ‘mismatch’ outputs of the last read are
OR’d together to set the PORTA Change Interrupt Flag
bit (RAIF) in the INTCON register (Register 2-3).'



i DO read porta bits individually prior to enabling intcon, even if i maybe didn't mention it.

(from Sesame Street)...
One of these sentences...is not like the other...

[xnihilo]

>>> NO !!! Won't work

How can you explain it works for me then?

>>> I leave your routine where it is ...

Again, i don't understand the meaning of this sentence.

Sado-Maso's little chicken warrior's game : Try it with real ammunition and real ennemies , you won't be so proud ...

What chicken?
It is a game meant to be a role playing game for cqb/mil-sim simulation.
Like Rainbow Six sgame series on pc.
What's your problem with that anyway?
Well that's not the point. I'm not here to discuss about RPG but about interrupts, am i not?

My idea is that the reason why i get unexpected interrupts is because i enable int for ra3 while this pin is left
floating... What is exactly the electrical/logical state of this pin (mclr disabled) when enabled as input pin with no external wpu, i don't know.

Maybe some smartass on this forum knows that :)

[xnihilo]

(from Sesame Street)...
One of these sentences...is not like the other...

let me explain.

1- i use INTCON = %10001000
it means i enable GIE bit, porta change int bit AND clear all interrupt flags. So i DO clear int flags.

2- in my previous project (called int.pcb, wonder why...), i didn't read porta before enabling interrupts (to clear potential mismatch), BUT ra3 was not enabled for int in IOCA register so it didn't trigger interrupt if not tied to vdd with a wpu.

[skimask]

1- i use INTCON = %10001000
it means i enable GIE bit, porta change int bit AND clear all interrupt flags. So i DO clear int flags.
Yep...sure do...and that's all fine and dandy...


2- in my previous project (called int.pcb, wonder why...), i didn't read porta before enabling interrupts (to clear potential mismatch), BUT ra3 was not enabled for int in IOCA register so it didn't trigger interrupt if not tied to vdd with a wpu.
But!....3 posts ago...one of those sentences is STILL not like the others...
And I had a look at your code...one small thing (I think) and you'll be set...

[Darrel Taylor]

Come on ski.

You're not being a "Teacher".
You are purposely tormenting him. And enjoying it.

It's a single line of code.
Just tell him.
<br>

[skimask]

Come on ski.
You're not being a "Teacher".
You are purposely tormenting him. And enjoying it.
It's a single line of code.
Just tell him.
<br>
But I'm not a teacher, heck, as you all probably know, I'm not even a programmer! :D
I am, however, a leader. Ask any of the guys that I trained to replace me, and they have...they'll tell you...(show me your war face! Arrrrrggghhhh!)
And I'm not enjoying it. It's like having a noob (at my job anyways) and trying to explain the inner workings of a synchro system and how it fully applies to an autopilot system...and he just doesn't get it (ran into this exact situation last week). Felt like slapping the kid across the flightline. Took him 3 days, then he came in monday morning with the answers and it had all clicked over the weekend (of course I had assigned him weekend duty just to try and comprehend the whole thing)...

[Darrel Taylor]

Remind me not to fly on one of your planes.

When people get thrown extra duty because they didn't know something and the boss refused to help.
It's likely they won't bother asking questions the next time they have problems.

Who know's what goes un-fixed.

Fine, I'll do it.

xnihilo,

i VAR BYTE

i = PORTA ' Clear mismatch condition
INTCON = %00001000 ' enable porta interrupts on change and clear flag

ON INTERRUPT GOTO in_sig ' int routine

Remove the other INTCON statement.

[skimask]

Remind me not to fly on one of your planes.
When people get thrown extra duty because they didn't know something and the boss refused to help.
It's likely they won't bother asking questions the next time they have problems.
Who know's what goes un-fixed.
WHOA! Don't get me wrong...I'm not that much of a jerk. They had it coming to them anyways...regardless if they would've had the answer or not.
And I had given them ALL of the tools they needed to solve the issue at hand.
And...don't forget...I'm a pilot myself. I know the responsibility that comes with having others living directly in your hands.
Sounds like a 'Hair Club for Men' commercial...
Not only am I a pilot, but I work on them too...

At any rate...I hope that fixes the issue with the program. I was going to fix it in a more roundabout way, but your solution works better.

[xnihilo]

Remind me not to fly on one of your planes.

When people get thrown extra duty because they didn't know something and the boss refused to help.
It's likely they won't bother asking questions the next time they have problems.

Who know's what goes un-fixed.

Fine, I'll do it.

xnihilo,

i VAR BYTE

i = PORTA ' Clear mismatch condition
INTCON = %00001000 ' enable porta interrupts on change and clear flag

ON INTERRUPT GOTO in_sig ' int routine

Remove the other INTCON statement.

Thank you very much, I'll report if it worked for me.

Have a nice WE.

[xnihilo]

But I'm not a teacher, heck, as you all probably know, I'm not even a programmer! :D
I am, however, a leader. Ask any of the guys that I trained to replace me, and they have...they'll tell you...(show me your war face! Arrrrrggghhhh!)
And I'm not enjoying it. It's like having a noob (at my job anyways) and trying to explain the inner workings of a synchro system and how it fully applies to an autopilot system...and he just doesn't get it (ran into this exact situation last week). Felt like slapping the kid across the flightline. Took him 3 days, then he came in monday morning with the answers and it had all clicked over the weekend (of course I had assigned him weekend duty just to try and comprehend the whole thing)...

Do you know the movies "SAW", I wonder why I think about it when I read your posts...

[skimask]

Do you know the movies "SAW", I wonder why I think about it when I read your posts...
'cause you like things like heating pads and shooting things I guess.
And no, I haven't seen SAW. Should have seen SAW? I'll ask the wife if she saw SAW...while she's on the see-saw. Maybe she saw SAW. Maybe I should go see SAW. If I saw SAW, maybe I'd see what you saw when you saw SAW. I'll report back after I see SAW to tell you what I saw when I saw SAW.

[xnihilo]

Remind me not to fly on one of your planes.

When people get thrown extra duty because they didn't know something and the boss refused to help.
It's likely they won't bother asking questions the next time they have problems.

Who know's what goes un-fixed.

Fine, I'll do it.

xnihilo,

i VAR BYTE

i = PORTA ' Clear mismatch condition
INTCON = %00001000 ' enable porta interrupts on change and clear flag

ON INTERRUPT GOTO in_sig ' int routine

Remove the other INTCON statement.

It looks like I could finaly prevent interrupts occuring without no reason.
I still have to thoroughly test the program.
I would like to know what's the need for GIE.
In your code above, you don't enable GIE at all, I followed your instructions and it worked.
I thought that in order for Interrupts for PORTA change (or any interrupts) to be enabled, GIE bit had to be set. I could not find clear information neither in pbp manual nor in the pic datasheet.

I have more strange things happening though, in my program just after the int routine label if I add an LCD output with the value of variable "a" bits (with a loop of 6 iterations and LCDOUT #a.0(i)) after an "a=porta" to get port pins values and clear mismatch), the value displayed doesn't change no matter what pin triggered the int (even if the right pin is detected), and ever more strange, after the interrupt routine is finished and before going back to the infinite loop, the value of portA bits is displayed once again, with no reason...
Subtleties...

Anyway, thanks a lot for your help, hope it solved the problem. It is still not crystal clear for me how to use stuff related to interrupts, I'm using the instructions more or less empiricaly and I'm not sure about the order in which I write the program sections.

If you have some time to waste, maybe you could have a look at my program and let me know if you see very horrible things ;)
http://users.edpnet.be/charlesetchristelle/squadtag/se230308.pbp

Best regards

[Darrel Taylor]

When using ON INTERRUPT, the GIE bit is controlled by PBP.
Any attempts to change it manually will cause problems.

And the IOC port change interrupt, doesn't save the state of the PINs for you. If you're just getting a quick pulse, it's possible that the pulse is gone by the time you try to display the pins, or determine who shot you with what.

The very first statement in the interrupt handler should read PORTA and save the value in a variable. Then use that variable throughout your handler, instead of the pins themselves.

The IOC interrupt also triggers on any pins transition from low to high, or high to low.
But your program is only looking for HIGH states. If it makes it all the way through the handler before the pulse goes away, then you will get another interrupt at the end of the input pulse. This time it'll look like all the pins are at their default state, as if nothing changed. You'll need to account for the second interrupt, somehow.

You're also clearing the interrupt flag in 2 places in the handler, one at the beginning, and another at the end of the handler. The first one attempts to clear the flag, before PORTA has been read. But it won't clear the flag, because the mismatch condition still exists.
Read PORTA first, then clear the flag.

At the end of the handler, it clears the flag, but doesn't read PORTA.
With things like LCDOUT's in the handler, it can take quite a while to complete the handler, and the PINs may have changed in the mean time, so it would be necessary to read PORTA again before clearing the flag.

hth,

[xnihilo]

When using ON INTERRUPT, the GIE bit is controlled by PBP.
Any attempts to change it manually will cause problems.


I didn't understand that when I read PBP manual section dedicated to INTERRUPTS.



And the IOC port change interrupt, doesn't save the state of the PINs for you. If you're just getting a quick pulse, it's possible that the pulse is gone by the time you try to display the pins, or determine who shot you with what.

The very first statement in the interrupt handler should read PORTA and save the value in a variable. Then use that variable throughout your handler, instead of the pins themselves.


I understand but then I need to poll the pin that triggered the int because I'm reading a PWM signal on a Infrared Sensor (that pulls the pin LOW) that looks like:
a header (1200us ON, 600us OFF, 1200us ON, 600us OFF), then 8 times (8bits) either 600us ON or OFF followed by 600us OFF spacers, then a 600us OFF (trailer).

By the way, is the following indexed byte variable bit accessing "variable.0(indexvariable)" correct? Everyone on the forum does not seem to agree.

a VAR BYTE
...
a = porta
for i = 0 to 5
LCDOUT #a.0(i)
next i






The IOC interrupt also triggers on any pins transition from low to high, or high to low.
But your program is only looking for HIGH states.


In fact, pins are HIGH because of the WPU, I'm looking for HIGH->LOW transitions.
Am I wrong about the use of WPU?

By the way, something strange in PIC16f684 datasheet: to enable individual WPU, OPTION_REG bit 7 has to be "0"... Strange, isn't it? Shouldn't the bit be set instead of cleared?




If it makes it all the way through the handler before the pulse goes away, then you will get another interrupt at the end of the input pulse. This time it'll look like all the pins are at their default state, as if nothing changed. You'll need to account for the second interrupt, somehow.



In my routine, there is a block that will scan the input on the triggering pin for the duration of the expected signal (about 14.4ms) so the interrupts will not be re-enabled until the 14.4ms duration has elapsed. Efter that, yes, another interrupt may occur if some signal arrives on a pin and the int handler will check if the signal has the right structure, duration and if the data carried is valid. I hope my algorythm was fine.



You're also clearing the interrupt flag in 2 places in the handler, one at the beginning, and another at the end of the handler. The first one attempts to clear the flag, before PORTA has been read. But it won't clear the flag, because the mismatch condition still exists.
Read PORTA first, then clear the flag.


Right.



At the end of the handler, it clears the flag, but doesn't read PORTA.
With things like LCDOUT's in the handler, it can take quite a while to complete the handler, and the PINs may have changed in the mean time, so it would be necessary to read PORTA again before clearing the flag.

hth,

You are geat, thank you so much for your explanations.

[Darrel Taylor]

In my routine, there is a block that will scan the input on the triggering pin for the duration of the expected signal (about 14.4ms) so the interrupts will not be re-enabled until the 14.4ms duration has elapsed. Oh, is that what it's supposed to do.
Might be a problem there. The comment also says 14400 uS, but those loops are going to take about 14.4 seconds instead.

FOR i = 0 TO 960 'total loop time: 14400 uS which is the total length of the bullet
PAUSE 15 'remember that the minimum delay at 8MHz is 12 uS
IF PORTA.0(area) == 1 THEN breakloop2
'when signal goes high, exit loop and check duration before the change, you need about 600us
NEXT i
Actually, it looks like all your comments show PAUSEs in uS. But the PAUSE statement delays in milliseconds.

You probably wanted PAUSEUS.

[xnihilo]

Oh, is that what it's supposed to do.
Might be a problem there. The comment also says 14400 uS, but those loops are going to take about 14.4 seconds instead.

FOR i = 0 TO 960 'total loop time: 14400 uS which is the total length of the bullet
PAUSE 15 'remember that the minimum delay at 8MHz is 12 uS
IF PORTA.0(area) == 1 THEN breakloop2
'when signal goes high, exit loop and check duration before the change, you need about 600us
NEXT i
Actually, it looks like all your comments show PAUSEs in uS. But the PAUSE statement delays in milliseconds.

You probably wanted PAUSEUS.

You are right, it is PAUSEus but for the test phase I replaced temporarily by PAUSE to be able to monitor what is going on with a 5V led.

[xnihilo]

There is a very strange thing happening.

I use RC5 without pullup and as an input at default 0V, I make it a 'listening' pin.
When a 5V pulse gets to this pin, I wait 1ms then set the pin as output and I set it high for 2ms. Then I turn it low and set is as input again to listen to any incoming pulses.

What's strange is that once the pic is powered on, an int is triggered as if porta was:
%00111111 while INTCON seems to be 0 (no int flag set).

Once the int handler has been processed once, the program behaves normaly.

So, there is obviously something that I don't grasp about setting a pin low or high and using WPU.

I should set TRISA register to determine which pin is used as input or as output.
I should use WPUA to determine what pin has its internal WPU enable. if disabled, the pin should stay LOW, shouldn't it?

If I explicitely write:

TRISA = %011111 'set RA5 as output, all other pins as inputs
OPTION_REG = %01111111 'enable individual WPU setting
WPUA = %011011 'enable WPU for all pins except RA3 and RA5
PORTA = %011111 'set all pins low except for RA5 (but WPU will bring HIGH all pins that have WPU enabled)

Like this I can expect to read porta as %011111 (31) but I get %111111 (63)...


updated code is at http://users.edpnet.be/charlesetchristelle/squadtag/se250308-2.pbp

[mister_e]

The link to the code is broken :(

Probably it would be safer to clear all interrupts flags before enabling any of them. When you enable the internal pull-up, this could trigger an interrupt.

i would suggest
enable the internal pull-up
clear interrupt flags
enable interrupts.

Did you also tried with real pull-up resistors?

[xnihilo]

The link to the code is broken :(


Sorry. I edited my post. Now the linked is fixed.



Probably it would be safer to clear all interrupts flags before enabling any of them. When you enable the internal pull-up, this could trigger an interrupt.


I take care of TRIS, PORTA, OPTION_REG, WPUA before I use INTCON=%00001000.
Your suggestion would be to use INTCON=0 before any other register setting and end with INTCON=%00001000
?
I will try this.




would suggest
enable the internal pull-up
clear interrupt flags
enable interrupts.


That's what I was doing in my code (in fact I enable porta change interrupts at the same time I clear all int flags). Still an interrupt is occuring but my int handler does not see what pin triggered the int so the handler is left with no action taken.
Maybe there is something else triggering an int (a timer???) but only porta change interrupts
are enabled.
Oh boy, these interrupts are so tricky...



Did you also tried with real pull-up resistors?

No because I need to enable and disable WPU in software.

[mister_e]

Is there any available schematic of it?

That's quite an ISR you have.... :( Usually it has to be kept as short as possible. I'll try having a look at this later.

Looking at the actual main loop... i'm not even sure if ANY interrupts are needed. Maybe just a read PORTA in a loop would do the job.

[xnihilo]

Is there any available schematic of it?

That's quite an ISR you have.... :( Usually it has to be kept as short as possible. I'll try having a look at this later.

Looking at the actual main loop... i'm not even sure if ANY interrupts are needed. Maybe just a read PORTA in a loop would do the job.

If fact I'm building 4 projects, all used in a lasergame system, one is the sensors module on the player, one is the gun itself, one is the mag (that manages all the bullets and spare mags) and the last one is the supplier for providing spare mgs and medics to players.

I've debuged the first three modules these 3 last days and I still have to take care of the supplier module.

All handshaking between pics is not tested yet, for debugginf phase, I preset the values to what's expected as a reply. The gun encodes a PWM signal to represent a header, a byte and a trailer, the sensors module gets the signal, checks structure validity then extracts the byte and use it.
I hope I won't encounter timing problems with that part.

Polling quickly portA won't be enough...

[mister_e]

So since then... what's new, something is better worst, code is still the same?

I hate guessing without schematic i can try and/or double check first...too bad!

[xnihilo]

Today I'm finishing the last module: the MAG module.
When done, I'll update my website with the specs for each system along with the schematics. After that only will it be possible to discuss further, I'll let you know when it is done. Thanks.