Wierd interrupt behavior: pins set up for interrupt sporadically retriggerable
CarlC
Posts: 29
I'm having a very strange interrupt behavoir on 2 RB pins. They appear to be properly initialized, but I was having problems with my system failing to respond to pin conditions which should have triggered interrupts. First I configured some RA pins as outputs to light some LEDs to give me a clue what parts of my code were being reached which was how I found out that interrupt handling was inconsistent. For some reason I was unable to get either pin to interrupt.
My code is meant to run at 50MHz which makes it tough to detailled debugging with LEDs so I configured 5 spare RB pins as outputs to spit out numbers at certain program places so I could trace my program with a datalogger. After putting the trace commands in, my program started behaving properly.
I haven't changed the way I set up RB except for setting some up as outputs. I note that when running code in debug mode, I have a strange issue where RB states don't update even though I've manually changed input conditions until I write to the 5 spare pins config'd as outputs.
Has anyone also experienced an input pin refresh issue with their SX micros?
Post Edited (CarlC) : 2/5/2006 9:23:47 AM GMT
My code is meant to run at 50MHz which makes it tough to detailled debugging with LEDs so I configured 5 spare RB pins as outputs to spit out numbers at certain program places so I could trace my program with a datalogger. After putting the trace commands in, my program started behaving properly.
I haven't changed the way I set up RB except for setting some up as outputs. I note that when running code in debug mode, I have a strange issue where RB states don't update even though I've manually changed input conditions until I write to the 5 spare pins config'd as outputs.
Has anyone also experienced an input pin refresh issue with their SX micros?
Post Edited (CarlC) : 2/5/2006 9:23:47 AM GMT
SRC
6K
Comments
as long as you have I/O pins configured as inputs, you can't manually change their states with the debugger. The displayed states in the debug window show what the SX "sees" at those pins, i.e. the external levels. These states may change randomly if you leave the inputs floating, so you better connect pull-up or pull-down resistors.
When you configure an I/O pin as output, the associated latch in the port output register is internally connected to the I/O pin. The debugger still displays what it "sees" at the I/O pins - in case of outputs, the output states are shown now. You then may manually change these states with the debugger.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
I realize that I can't change input pin conditions in the debugger. I was bug tracing while running my program regularly. I placed commands to light LEDs at various program points with no instructions to clear the LED. That way when a point was reached, an LED was lit and left on so I didn't have to try to catch an LED flashing at MHz type frequencies.
I was using the RA port to control LEDs and found that RB configured interrupts weren't triggering consistently with signal inputs which should have worked. I suspected that I got stuck in a loop somewhere and tried leaving LED test points througout my code and wasn't able to get a clear consistent picture as I wasn't able to follow the flashing lights quick enough.
I then laid commands using 5 spare pins in the RB port which were config'd as outputs so I could trace the pin state in a high speed manner with a datalogger which would simultaneously monitor the 2x RB interrupt inputs and the 5x RB outputs so I could see where the program was running.
When I made the changes, the program mysteriously started functioning correctly even though I hadn't put any instructions which should have affected program flow.
I've gotten a bit further. I've commented out most of my code which was outputting bits for my datalogger. I found one command which mysteriously fixes things. It's at the end of my ISR. All it does is raise a RB pin config'd as an output. Wierd because it doesn't get cleared anywhere. Once it's set, it's never cleared again. It doesn't even seem to matter if I output to RA or RB output pins. All I can guess is that it makes the processer look at ports once more to reset interrupt behavior.
I've attached code. Maybe I've found something new?
Post Edited (CarlC) : 2/5/2006 9:37:44 AM GMT
Inputs at I/O, DAV, ATN defined pins are from another SX28 that I've programmed to blast out signal according to a scheme which simulates a signal train I intend to monitor at just under 1Mb/s. I'm pretty sure that this is working right as I can confirm the output with my datalogger.
I can confirm that the scanning SX28 is working right with the code I use for bug tracing enabled (commented "in") in the ISR as the outputs for the scanning SX28 are working right. I also get the right numbers outputted on the RB output pins when all of the bug tracing code is commented in because the datalogger catches the right outputs.
Does anyone else use similar tricks to trace bugs in regular running mode? I found that catching trace numbers to be a handy method in conjunction with a data logger. It doesn't affect timing too much and you can catch high speed effects like switch bounce or signal issues.
Why are you loading the WK_PND register with $FF ? I see you do later load it with $00 before exiting the ISR. But $FF would indicate that ALL bits had caused an interrupt.
Normally I load WK_PND with $00 (while getting the current status), as the very first thing. Then don't do it again in the ISR (that way if another bit causes an interrupt while you are IN the interrupt routine it won't get "lost", it will just trigger another interrupt as soon as the current one if finished.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"SX-Video·Module" Now available from Parallax for only $28.95
http://www.parallax.com/detail.asp?product_id=30012
"SX-Video OSD module" Now available from Parallax for only·$49.95
http://www.parallax.com/detail.asp?product_id=30015
Product web site: www.sxvm.com
"Ability may get you to the top, but it takes character to keep you there."
·
The $FF load is an anachronism when I thought loading $00 would re-enable interrupts prematurely. I had thought that loading $00 would allow an interruption of my ISR. I now realize that the RETI enables interrupts again. However, the $FF load is to swap the interrupt cause into W to affect how my ISR responds to one of two sources of interrupt.
I did not know that an interrupt while the ISR was running would que up a subsequent interrupt. Perhaps my strange running is associated to that somehow.
I'm not sure how as adding in the SETB instruction at the end shouldn't affect the flow of my code much as the SETB is to an output pin. I'm baffled why the write to RB has to be at the end of my ISR. If I enable the RB writes at the beginning but comment out the writes at the end, I have different program flow than when the writes are put at the end.