This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
I am looking for some general debugging help. I have some algorithmic calculations being run on my MSP430F47183 in the SD16 interrupt. I am also running simpliciti with it to communicate with another module wirelessly.
My general question is stated in the topic title, what are some debugging techniques that would help me to determine why the MCU resets under certain conditions?
The SD16 interrupt needs to run very regularly at 8kHz, about every 125 us. However, when other modules try to join the network using the SimpliciTI protocol, the Rx interrupt processes for about 260 us, delaying the SD16 and causing calculations be inaccurate. Chip runs fine, until I attempt to nest interrupts by setting GIE in the Rx interrupt, in which case the MCU resets itself about 1.5 ms after the Rx interrupt fires. The SD16 interrupt fires several times or more in that period before resetting. The Rx interrupt also interrupts itself before a previous instance of it finishes. In fact, the Rx interrupt never finishes before reset.
Any suggestions or advice would be much appreciated.
Before you can enable GIE inside an ISR for interrupt nesting, you'll have to ensure that the cause for the current interrupt has been removed (the IFG bit cleared etc.). If not, the ISR will immediately interrupt itself again and again, causing a stack overflow.
If you do, but still a new interrupt comes beore the first is handled, you may want to temporarily disable the interrupt by clearing the associated IE bit, then set GIE to allow other interrupts to be handled, and then when you're done, clear GIE and set the IE bit before exiting the ISR.
Nested interrupts are a very complex and dangerous field.
Time to say goodbye - I don't have the time anymore to read and answer forum posts. See my bio for details.Before posting bug reports or ask for help, do at least quick scan over this article. It applies to any kind of problem reporting. On any forum. And/or look here.I'm sorry that I can no longer provide help in the forum or by private conversation.
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to Jens-Michael Gross:
Awesome, thanks. That makes total sense. I got it working now.
Previously I was clearing the pin later in the interrupt. It would never reach there because it got interrupted by my SD16 interupt.
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. 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.