I am using CCSv4 and my SWIs are configured by CCS configuration tool or by editing the tcf file. How can I kill a queued SWI from a running SWI?
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.
Search for answers, Ask a question, click Verify when complete, Help others, Learn more.
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.
If you are using a SWI (all capitals) then it is DSP/BIOS, and version 220.127.116.11 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…
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.
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.
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.
Use a PRD function.
If you need more help, please reply back. If this answers the question, please click Verify Answer , below.
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?
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.
I will recommend that you go through some of the BIOS training material that TI offers. You started this thread with a detail that is not covered there, but your questions now are ones that are addressed by the online training material. These training sources will help you understand things that you do not yet know to ask about and this will improve your successes with your project.
Please go to the TI Wiki Pages and search for "BIOS training" (no quotes). You will find several links and some will offer multiple choices. Look through those for the ones that seem best suited to you. My recommendation is the "C6000 Embedded Design Workshop Using BIOS" page as a starting point, with a link to the archived version 5.93 which dealt with DSP/BIOS instead of the newer SYS/BIOS.
The DSP/BIOS User's Guide explains what the PRD functionality is and how it compares with SWIs. The training material may be the best way to get introduced to the concepts
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.