We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
I have a reasonably stable program written using the TIM Example as an original basis( RV30\Examples\ST\STR73xLIB\TIM ).
Now I am experiencing problems with re-entering a UART interrupt when I dont want to ( recursion ).
I assume I am using the ST type interrupts as opposed to Keil type, and will happily change if this will make things easier, but I cant see why the 'I' mask is cleared as soon as I break on the interrupt routine - does the EIC module do it, or is there some header code doing it that I cant see.
I was under the impression that one had to clear the 'I' flag specifically if nested ints are required, but I certainly am not doing this myself. It would be useful to understand whats going on before I move on.
TIA.
Hi Mike, I believe your correct, having briefly traced this through. It is as I had expected. It seems like its taking a liberty though, because if you actually *DONT* want interrupts re-enabled, there is a window of time before this wrapper code enters your own routine from where you could disable it. However, within that period, a new interrupt and unwanted recursion could occur. I am re-coding to use the Keil Style interrupts which I presume avoids this scenario. Welcome any further comments on this as I am still new to using the device.
Another option would be to re-code ST's ISR wrapper. I have done that and I believe that my code is smaller and faster than ST's. The drawback of my code is that you have to enable interrupts within each ISR to allow interrupt nesting, but that is actually an advantage in your case. I could email the code to you if you wish.
Regards, - mike
Mike; Will your Int routines run with RealView RTOS? Using the Keil RTX you must disable EIC setup in Startup. Keil claims their Interrupt Lib functions are much faster than the general purpose STR7x Lib functions but require special handling for initialization. Using the Keil RTX prevents the use of the the STRx Libs according to Keil notes. The on-line manuals and the CD manuals don't give a lot of info on proper handling of possible nested interrupts. Most of the info must be dredged from the Keil Lib source files. But of course, we all know that 'C' code is self documenting right? We are having a problem with interrupt collison between out UART0 (random keyboard use) and XTI 10mSec edge triggered A/D interrupt. The problems occurs about every second rainy Tuesday of the week. Any suggestions are appreciated. Bradford
Actually while debugging my application I found that when using my IRQ code, nested interrupts may cause corruption of CPU registers and/or CPSR. So much for smaller and faster code :-) I'll have to sit down and look very carefully at my code, or revert to ST's one. The description of EIC in the microcontroller reference manual is not exactly straightforward, which doesn't help. The lesson to learn here is that unless you are prepared to study the inner workings of interrupt handling in STR7x, get code you can trust to work. In your situation, if you are using ST's interrupt handling code, it should be easy to modify it to not re-enable interrupts before entering ISR. Then you'll be able to re-enable them in ISR if you need to. I would suggest a method of debugging such problems that worked for me. If you think that a bug is caused by a combination of two interrupts, make the interrupts trigger more frequently if you can. This way you won't have to wait long for the bug to manifest itself.
Thanks Mike; I have picked up support of this code while the programmer is on vacation. I'm trying to find my way through his code. It appears pretty clean. I followed your advice and made some strides. My A/D is not on the STR7 chip but is a high speed A/D driving some pre-processing in an FPGA. The FPGA interrupts the STR7 at 10mSec rate via the XTI. Servicing that interrupt take a couple of microsecs. I placed the UART0 function in a tight loop driving a simple ASCII data stream. Between the two there was no apparent problem. BUT, each time I attempt to use the keyboard my failure time is between 5 and 10 minutes of operation. So, I'm slowly defining the problem. I'm using the Keil versions of the STR71x Libs as suggested in the RTL manuals. Thanks again. Bradford
Stack space! As we increased our use of muliple interrupts we overran our stack space. A very typical shot in the foot programming. Running smooth again for now. Bradford