Tasking/Interrupt problem? in GSTART runtime env. from Green Hills

Tasking/Interrupt problem? in GSTART runtime env. from Green Hills

[Mathias]

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