Timer Interrupt Conflicts - ADuC831

I know that this problem is pretty broad, especially w/o code to back it up, but I am having some issues with an Analog Devices ADuC831 and I thought I would ask you guys to see if you have any ideas.

Here is the system. I am using the 831 as a Microcontroller for a data acquisition and transmission system. The transmissions are done via physical pulses (think morris code) which are time critical. They are controlled via timer 1 operating inside the interrupt itself (very small amount of code - about 35 lines of assembly).

The data acquisition system pulls data off an A/D converter on another device which reads in the analog data. This is done via the SPI and also somewhat time sensitive, though not as much, so while timer 0 triggers this event (setting an alarm flag), it is held in main.

Now by themselves, the two systems work great. No problems at all. The problem I am running into is when I am trying to combine these systems. Then the system will hang during acquisition. It also appears that the problem is when a pulse is being sent out via the interrupt.

Now, as far as I can tell, the only two shared bits of memory is the accumulator, which I am backing up during interrupt handling. So I am stumped.

Any ideas? Let me know if you need more data, because like I said, I know this is a very broad question.

RonB

-------------------------------------------------- "It is human nature to take shortcuts in thinking"

--------------------------------------------------

Reply to
Ron Blancarte
Loading thread data ...

I would start by looking very closely at the timer configurations and interrupt service routines. From your description, I suspect that the timers interact in such as way that one or both of them are getting disabled or something when they expire relatively close in time.

You could better define what you mean by "hang". Does the system stop completely or does it continue to perform SPI I/O but not generate the morris (did you mean "Morse" as is telegraphy) code.

Do you have a debugger that allows you to suspend the system and examine the timer registers after the system goes into its failure mode? Do you have an oscilloscope that you can use to observe the various I/O lines and get information that could give you clues concerning what aspects of the system stop working?

--
========================================================================
          Michael Kesti            |  "And like, one and one don't make
 Click to see the full signature
Reply to
Michael R. Kesti

Good point. Actually - by hang I mean the main hangs (I am currently in the process of figuring out exactly where). The system appears to continue running, because the pulsing continues, though new values are not loaded into the "pulser" (because this is handled by main), so it continues to pulse the same character. Clearly the interrupts are still being handled, since the pulses are being produced. HOWEVER, something is causing main to get hung and do nothing.

Debugger - no. I wish I did, it would make life so much easier.

Scope/etc - working on it. However, it is hard w/o direct access to the pins. Though I do have a lot of free ones that I could easily dump signals onto so I can measure what is running and what isn't. Granted I could EASILY get to the pins...

This does raise a good question - does anyone know of a company that makes a chip clip for the ADuC831? Thanks.

RonB

-------------------------------------------------- "It is human nature to take shortcuts in thinking"

--------------------------------------------------

Reply to
Ron Blancarte

Good guess. After digging around all day yesterday I found the problem. It turns out that my Timer 1 interrupt was interfering w/ my ADC interrupt (the internal one that is used sparingly). Anyway, I was getting hung at a while loop that must have never had the value change (the ADC Interrupt flag would always stay high). I changed the code and it seems that hanging problem disappeared.

As to why this problem appeared with the other events - my guess is that it widened the window in which this problem could appear, when I turned on acquisition. It caused the timer routine to bog down some and thus this event had more opportunity to fail. An interesting note, when heat testing my part last night I saw, for the first time, this bug without the acquisition events turned on, so this bug has been present for a while, I just never saw it under a plain run (pulsing no acquisition).

Thanks for the help!

RonB

-------------------------------------------------- "It is human nature to take shortcuts in thinking"

--------------------------------------------------

Reply to
Ron Blancarte

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.