nested interrupts

[cebotor]

Posted on December 23, 2008 at 05:58

nested interrupts

[cebotor]

Posted on May 17, 2011 at 12:57

Hello Joseph.yiu !

''....which would lead to a fault...'' - its considering that value of execution return is copied from the source frame stack ? so it will be not 0xfffffffe .It will be 0xfffffff1? Offset about with you write, its because i use IAR IDE. In IAR (5.11) ISR header looks like in the sample above, will be generated with this offset in stack frame . Yes, you are right, better way is put the handler code in asm. Thank you very much, Joseph !

[joseph239955]

Posted on May 17, 2011 at 12:57

Hi cebotor,

If you copy the EXC_RETURN from original stack frame, then it will be fine. If you create a dummy stack frame with a fixed EXC_RETURN, then it could lead to hardfault if it is in a nested interrupt case. I have just done a quick test with the handler being written in asm, and then call the C function. I didn't copy all the register to the dummy stack frame as it is not used by the C handler. systick_handler_wrapper SUBS SP, #0x20 ; Save space for dummy stack frame ; This prevent dummy stack frame being created destroyed by ; new interrrupt ; Create dummy stack frame LDR R0, [SP, #52] ; LR in real stack frame STR R0, [SP, #20] ; LR in dummy stack frame LDR R0, [SP, #60] ; PSR in real stack frame ANDS R0, #0xFF ; Preserve IPSR ORRS R0, #0x01000000 ; Set T-bit STR R0, [SP, #28] ; PSR in dummy stack frame LDR R0, =systick_handler_testpoint1 ; Return address ;(with ARM asm, LSB is set by LDR automatically as it is instruction address) STR R0, [SP, #24] ; Return address in dummy stack frame BX LR ; Exception return - ; goto systick_handler_testpoint1 systick_handler_testpoint1 BL systick_handler_in_C ; Running your C function SVC 0 ; Use SVC to trigger return with original stack frame svc_handler_wrapper ; Ending of handler ADDS SP, #0x20 ; Remove dummy stack frame BX LR Hope this help. Joseph

[cebotor]

Posted on May 17, 2011 at 12:57

Hello Joseph!

Tnank for sample, its just what i need. however i put strings which set basepri before SVC becouse in other case its possible to get other exception between line SVC 0 ; Use SVC to trigger return with original stack frame and line svc_handler_wrapper ; Ending of handler I saw it in practice just now in my variant of wrapper.

[picguy]

Posted on May 17, 2011 at 12:57

cebotor wrote . . .

>Its great idea to use queue to solve this problem, but.. its does not work because ISR Y anyway could not be interrupted with ISR Y. >We can make queue from ISR X , which will interrupt ISR Y , but ''ISR Y processes the queued work requests in order'' only when first copy of ISR Y will be completed. Or I have misunderstood you, Picguy? Somewhat misunderstood. But let’s go back to what I understand to be the problem you are trying to solve: You have events that happen faster than you can process them. I also assume that you will not get so buried with so many events so fast that you run out of CPU time. It seems fair to assume that you will never be more than perhaps 10 or 20 processed events behind your primary source of interrupts. Or at the very least you have an upper bound based on the function of your system. You do not want to go endlessly deeper and deeper into an ISR stack. Indeed, if you find a way to do this you will eventually run out of RAM. I.e. your problem must be solvable on the given hardware platform. My original thinking had ISR X triggering ISR Y after queuing every event. ISR Y processes each event in turn, LOOPING BACK UNTIL THE QUEUE IS EMPTY. ISR X can add entries as ISR Y runs. With a little care this can work well. (Make the worst problem ISR Y finding nothing to do. It should exit doing nothing.) Thus ISR Y does the actual processing sequentially while additional events continue to arrive. Implicit in this structure is that the work done by ISR Y is work that is best done in an ISR. Thus serial processing in ISR Y only slightly after the fact is the way to go. In this pure ISR approach Y is not interruptible by another ISR Y. You point this out in your comments to me. You could build a mini ISR Y scheduler and multi task within ISR Y. Such an approach may be worth the effort. Or this may work: the queue sourced by ISR X could be sinked in some non-ISR multitasking environment. One presumes these tasks should be fairly high priority. Perhaps one task for each event type. Depending on your application you may wish to use ISR Y to dequeue what ISR X generates. ISR Y then performs fast operations itself (adding one to a counter is fast) and sends slow requests off to some underlying multitasking OS. Using my first response you should be able to email me. I can provide a LITTLE design assistance for free.

[cebotor]

Posted on May 17, 2011 at 12:57

Hello,Picguy!

Using fifo queue is good method to process some events that happen faster than we can process them. But i think can not be a substitute for method with wrapper, which should increase latency of system. Nested execution of tasks must allow small tasks to interrupt a ''big'' tasks. Thanks for the offers of assistance.