How to kill a statically configured SWI

Zhou,

Please tell which version of BIOS you are using and which device this will be used with.

Please explain fully what you mean by "kill".

This thread will be moved to the BIOS Forum because this is a BIOS question. Please post software questions to the appropriate forum.

Regards,
RandyP

Hi RandyP,

Thanks for moving the thread to the right forum.

I found 3 directories in my CCS installation which may be related to your question:

C:\Program Files\Texas Instruments\bios_5_41_10_36

C:\Program Files\Texas Instruments\bios_6_31_04_27

C:\Program Files\Texas Instruments\C6000 Code Generation Tools 7.0.3

Is my bios version 6.31?

By killing an SWI, I mean that if a new SWI is running and an old SWI was suspended, I want to remove the old SWI from the queue because the info or context used by the old SWI may have been invalid. I want delete the old SWI so that it will not continue to execute when the DSP is available, unless a now SWI_post() is called for it. My SWI was posted by SWI_post(&my_swi_name).

I am looking forward to your reply because I am fixing an urgent issue.

Thanks.

Zhou

Zhou,

If you are using a SWI (all capitals) then it is DSP/BIOS, and version 5.41.10.36 from your install info.

If I understand your situation right, you have a SWI that is executing, and then it gets preempted because a higher priority SWI is readied to run.  And within that higher priority SWI, a decision is made to not continue the execution of that previously executing (but preempted) SWI.  Is that the case? 

If so, I don’t think there is any way to cleanly do that.  Because, the context of the SWI that was preempted is sitting on the stack, and the higher priority SWI’s context has ‘stacked’ on top of it.  To properly unwind the stack, that previous SWI must resume, and then finish its execution.

There is an API to delete a dynamically created SWI (SWI_delete()), but that can’t be called from SWI or HWI context.

I wonder if for your case you can use an application-managed flag for the SWI that can be preempted? The higher priority SWI writes to that flag to tell the lower priority SWI to *not* continue because it was preempted.  And before that lower priority SWI does anything that it shouldn’t (after being preempted) it checks that flag to make sure it is OK? 

You’d likely need to do a SWI_disable() before that lower priority SWI checks the flag and does its work, which will hold off the higher priority SWI from being able to run immediately, until SWI_enable() is called. 

When that lower priority SWI sees the flag that says ‘don’t continue’, it clears the flag and then the function returns.  Then the SWI will be "done", but will still be available to be posted to do work again.  It just finished earlier than it normally would.

It is a bit messy, but maybe it will work for your use case?

Hope this helps…

Scott

Thanks Scott.

Sorry to know that there is no way to clean a stacked SWI.

Your proposal is what I have been thinking of, however it adds overhead. This is why I am reluctant to implement it.

Zhou

Zhou,

The solution Scott has outlined and that you have considered is the only direct answer to your question. With no other insight into your application, this is the only type of suggestion we can offer.

It does make sense that something new (the higher priority SWI) could overwrite the input data or the output data of something old (the lower priority SWI). But it would seem possible that the lower priority SWI may have completed and you would not worry about it. In that case, it may be better to reconsider your priority settings for the SWI so that the first SWI will always complete before the second SWI begins.

Another option could be to block the output of the lower priority SWI once the higher priority SWI has detected that the lower priority one is running. If the output is using a pointer, that pointer could be changed, but you have a race condition that would depend on where in the lower priority SWI the pre-emption occurred. Or if the output is moved at the end, that operation might be the only one that is blocked. Some portions of the lower priority SWI should be protected by the SWI_disable/_enable pair that Scott mentioned.

The best solutions are always systemic solutions. Arrange the priorities and sequences to do things the way they need to be done instead of patching them to get there.

My opinions, for what they are are worth.

Regards,
RandyP

Thanks RandyP and Scott.

How can I have a higher timer interrupt which is "definitely to run" if no higher priority interrupt blocks it? Then I can use this timer to periodically clear the contents (assuming they are in global buffers) which are generated by the old SWIs.

Zhou

Zhou,

Use a PRD function.

Regards,
RandyP

If you need more help, please reply back. If this answers the question, please click  Verify Answer  , below.

Thanks RandyP.

I do not know how the priority of PRD over SWI. Will PRD always run when its period expires and it will always pre-emption SWI?

Zhou

Zhou,

PRD functions run in the context of a SWI; more specifically they run in the context of the SWI called "PRD_swi."

So, the PRD function can be preempted by a SWI of higher priority, or by a HWI.

Steve

Thanks RandyP.