From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,a09d7f0511023666,start X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-11-08 04:23:08 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: l_mathias@hotmail.com (Mathias) Newsgroups: comp.lang.ada Subject: Tasking/Interrupt problem? in GSTART runtime env. from Green Hills Date: 8 Nov 2002 04:23:07 -0800 Organization: http://groups.google.com/ Message-ID: <9b051957.0211080423.16fd0436@posting.google.com> NNTP-Posting-Host: 146.75.247.241 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1036758188 3577 127.0.0.1 (8 Nov 2002 12:23:08 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 8 Nov 2002 12:23:08 GMT Xref: archiver1.google.com comp.lang.ada:30581 Date: 2002-11-08T12:23:08+00:00 List-Id: Hi all I have encountered a problem which I think is related to the scheduler in the Ada runtime environment. I have run out of ideas and wonder if someone out there can help me get back on track. I have an interrupt driven Rs232 driver which writes received data to a circular buffer (Rs232-RxBuffer, not a protected object)and reads data to be transmitted from another circular buffer (Rs232-TxBuffer, not a protected object). I also have an application containing two tasks. One that reads data from the Rs232-RxBuffer and another that reads data from an Ethernet interface. This runs on the GSTART runtime environment from Green Hills on a Motorola 8245 PowerPC processor. The Rs-driver's interrupt handler is called from the GSTART interrupt handler, which in turn is called from the processor interrupt handler. The processor interrupt handler only generates one UART interrupt and it is up to the Rs-driver interrupt handler to read a register to find out which interrupt it actually is (Data received, Transmitter ready, Receive error...etc.). While debugging I have stripped my system down to the Rs-driver and an application with two tasks that writes a string each to the Rs-driver, enables the UART Transmitter ready interrupt and then goes to sleep for a while. The stripped system works fine, the two tasks writes their strings and everyone is happy, until the Rs-driver receives a character. The actual reception works fine, but when the interrupt handler is finished and one of the tasks is in turn for execution (sounds brutal...) it doesn't start. The other task continues to run until another character is received and the scenario repeats. When both tasks are "dead" the interrupt handler continues to work fine. If I, after reception of a character, halt the execution the debugger often stands on a line which I interpret as an infinite loop in the runt-time scheduler. This might be OK since I don't know which task the debugger is attached to. Sometimes the debugger halts in operations which appear to restore registers during a context switch. If you want to email me my address is mathias/larsson/combitechsystems/com (replace the slashes with dots). Regards /Mathias