Turning on and off RTCC interrupt in a subroutine problems??????
Hi guys,
I have got an issue where the RTCC interrupt keeps firing in the middle of my subroutine. I have put in code to turn the interrupt off in the subroutine before I do anything and then turn it back on after I have finished. Can I actually do this? As it doesn't seem to be working. If I turn the interrupt off at the beginning of the code, it runs perfectly.
SX48 Datasheet doesn't offer much information on this.
Any tips or suggestions, the interrupt has to stay as it is used as a base timer for timeouts in other subroutines.
Cheers
Stolzie
I have got an issue where the RTCC interrupt keeps firing in the middle of my subroutine. I have put in code to turn the interrupt off in the subroutine before I do anything and then turn it back on after I have finished. Can I actually do this? As it doesn't seem to be working. If I turn the interrupt off at the beginning of the code, it runs perfectly.
SX48 Datasheet doesn't offer much information on this.
Any tips or suggestions, the interrupt has to stay as it is used as a base timer for timeouts in other subroutines.
Cheers
Stolzie
ReadEE ; ; Read Word at EEAddr to EEDatL,EEDatH ; ****************************************************************************** mov w, #%01001000; #(RTCC_PS_OFF) ; setup option register mov !option, w clrb SPI_CS call @E2Delay300nS clrb SPI_CLK setb SPI_CS _bank SPI_BANK mov spim_out_dat,#$01 ; send start bit call @spia ;rl,rl eeadr and then clear carry rr clear carry rr ;this will set bit 6,7 to known state of $00XXXXX ; _bank EEPROM_BANK ; rl EEAddr ; rl EEAddr ; clc ; rr EEAddr ; clc ; rr EEAddr ; mov w,EEAddr ; xor w,#$80 _bank SPI_BANK mov spim_out_dat,#$80;w ; move $00 Control byte for EWEN call @spia mov spim_out_dat,#$00 ; move EEDATH call @spia mov globtemp1,spim_in_dat mov spim_out_dat,#$00 ; move EEDATL call @spia mov globtemp2,spim_in_dat clrb SPI_CS setb SPI_CS _bank EEPROM_BANK mov EEDatH,globTemp1 mov EEDatL,globTemp2 mov w, #(RTCC_PS_OFF) ; setup option register mov !option, w retp
Comments
depending on how often the interrupt is fired, and how many clock cycles are required to execute the instructions in the ISR, the interrupt "steals" away clock cycles from the main program (or any subroutine called from there). IOW, it slows down the execution speed of the main code. As long as the main code is not time-critical, this is not a problem. In your case, the code handles communications via the SPI bus which is not really a time-critical operation, as the code generates the bus clock. Therefore, I wonder why cour code does not work correctly when you allow for interrupts, as it normally should.
I made a similar experience in the past, and I found out that the ISR code - by mistake - did modify register contents that were supposed to be left un-touched. This can easily happen when you forget to select the correct bank within the ISR before accessing registers. So, in this case, the reason for the problem was not the interrupt per se, but bad code inside the ISR. When another bank is selected within the ISR, there is no need to restore the original bank because the FSR is automatically saved on entry, and restored on exit from the interrupt.
BTW: The SX48 also saves the contents of the MODE register when the ISR is entered, and restores it on return from the interrupt, where the "smaller" SXes don't have this feature. I just mention this here to make other lurkers aware of that fact when writing ISR code for the SX20/28.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
It is strange that the code does work without the interrupt and not when it is on.
The EEPROM I am trying to talk to is a 93LC46B
in the ISR code you have posted, following the ":LedTimer" label, you do a "_bank FLAG3_BANK", set the "TURN_LED_OFF" flag, and after the "nop", you continue with "incsz arpTimerLSB", and eventually you also do an "inc arpTimerMSB".
Are those two timer registers really located in the "FLAGS3_BANK" (the active bank at that time)? If not, you would mess up some other registers here. So you better replace the "nop" with a "_bank TIMER_BANK".
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
Cheers
Stolzie
It's not clear to me why you need to turn off interrupts. You say that interrupts fire during the processing of your main routine. So what? Billions of CPUs around the world have interrupts fire off all the time. The whole point of interrupts is that they fire off, get handled, and then return control to the main loop - all without affecting the main loop.
If you've got timing sensitive issues in your main loop, then perhaps you need to think about your software architecture and move the timing critical code to the interrupt itself. One of the great things about interrupts is that they handle timing critical stuff all the time.
If you have code that just sits in a loop until a count reaches a certain value before moving on, then you've got software that blocks and grinds to a halt all the time. This type of code is hard to maintain over time as you are constantly trying to figure out how to keep things moving and stopping simultaneously.
Thank,
PeterM
Thanks for the reply. I have definitely got some weird stuff happening with my board/code.
I will leave the interrupts on regardless as they are needed for other pieces of code, but it seems strange that if I turn the interrupts off the same piece of code works fine and when I turn the interrupt on it doesn't!
And I am at a loss to why it is doing this weird stuff. oh well some more debugging is required!
Thanks for the reply.
Cheers
Stolzie
I have discovered that my write code with interrupts on is functioning correctly but the read is not. It is constantly spitting back $FF, if the interrupts are disabled it will read the correct value every single time.
Cheers
Stolzie
as you had only posted part of your program, it is pretty hard to check the code for potential errors. It would be helpful to see the complete code, or at least the variable declarations.
I don't think that an active interrupt per-se causes the problem you have - there must be something inside the ISR code that messes up something outside the ISR. BTW: did you fix the missing _bank instruction in the ISR?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
I fixed up the missing bank routine, and it still had the same problem. I have since tried a few things and have commented out the bank instruction that I added and the instruction below it.
;***************************
;_bank FLAG3_BANK
;setb flags3.TURN_LED_OFF
;***************************
And I am now able to read the eeprom values! Obvioulsy it may have something to do with the ISR and possibly the RETIW at the end of the interrupt.
Will post up the defines tomorrow, but at least it is starting to come together.
Cheers
Stolzie
ISR extract
Cheers
Stolzie