Problem with KBI on MC13213

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Problem with KBI on MC13213

3,653 Views
chapster
Contributor I
I am using the MC13213 (based on the gt60) and am having a problem using the KBI.  I am using 2 encoders connected to PTA4-7.  I set them up as follows
 
KBI1PE = 0xf0;  // enable PTA4-7 as interrupts
KBI1SC_KBACK = 1;  // clear ack
KBI1SC_KBIE = 1;   // enable interrupts
 
Both encoders will generate interrupts but PTA6 and PTA7 will not generate an interrupt if PTA4 or PTA5 is 0 on startup.  Once one of them has generated an interrupt 6 and 7 always can regardless of the state of the other 2 pins.  Also, if the 4 and 5 are 1 on startup then they do not need to generate an interrupt before 6 and 7 can.  I can not see any reason for this behaviour and I do not change the KBI registers anywhere else in the code.
Labels (1)
0 Kudos
Reply
5 Replies

901 Views
bigmac
Specialist III
Hello,
 
If you look at the simplified schematic data for the KBI module, you will see that all the enabled KB inputs are ORed together before being fed to the interrupt generating circuitry.  Assuming that the interrupts will be edge-only triggered, and the PTA inputs will respond to a negative edge, if any one of the enabled inputs goes low, it will generate an interrupt only if none of the other enabled inputs is already low.
 
Once an interrupt has occurred, if you need to sense whether any other input has been activated, you would need to poll the port status prior to exiting the ISR.  If you were to temporarily disable any low state input from the KBI (from within the ISR), this would enable the other inputs to also generate an interrupt.  Alternatively, you might flip the edge polarity so the next interrupt for that input would occur on the positive edge.
 
If the encoders you are using are also subject to switch bounce, you will need to disable each input for a suitable switch de-bounce period following a transition.
 
Regards,
Mac
 
0 Kudos
Reply

901 Views
chapster
Contributor I
Works fine now, no problems.
0 Kudos
Reply

901 Views
chapster
Contributor I
Thanks for the quick response!
 
You are correct, I am using edge only triggering and I am changing the flow polarity once an input changes state and have allowed 1ms for debouncing (I have measured a maximum od 0.5ms which caused early problems).
I do not disable low inputs but I do change the polarity once they are have generated the interrupt and gone low, which I am guessing has the same effect. This is probably why once both encoders are working they always will because the polarity is always correct.
 
If I read the states of all the inputs at the beginning and set the edge polaritys accordingly this should work. 
 
Thanks for that
0 Kudos
Reply

901 Views
bigmac
Specialist III
Hello chapster,
 
There is a further issue associated with changing the polarity of the KBI that I have just realised, and which I assume you have already addressed to make the arrangement work.  Whenever a KB input is enabled, a pull-up is automatically implemented for a negative edge.  However, if a positive edge is then selected, the pull-up becomes a pull-down - probably not what the encoders require if mechanical switching type.  I guess the simplest solution would be to over-ride the pull-down current using external pull-up resistors of sufficiently low value.
 
My gut feel would be to allow somewhat more than 1ms debounce interval - to allow for wider unit-to-unit variation, and cater for possible degredation over time.  Are the encoders used as manually actuated controls?
 
Regards,
Mac
 
0 Kudos
Reply

901 Views
chapster
Contributor I
Hi Mac
 
Yes it is a manual control.  I am not using the internal pull ups because as you say they change to pull downs when the edge polarity is changed.  Although I haven't seen any really bad bouncing on the encoder switches I suppose it may get worse with time so I may extend the debouncing time.
 Thanks again for your help 
0 Kudos
Reply