Hello,
we are using a double UART SC16IS752/SC16IS762 chip on the SPI2 bus mounted on a IESM card.
We use an external interrupt with a low level handler. When the interrupt is generated,
we use the “adl_msgSend” to signal the interrupt to an appication task to perform the reading
of the interrupt identification register and do the necessary work subsequently the interrupt event.
The things work well on low level of incoming data, but on higher levels of incoming data
we get very often an overrun error and we loose some data.
In this case we need to reset the chip to continue normal serial in/out operation.
Normally in other environment systems the interrupt identification register reading
is performed directly in the interrupt event handler, but in OpenAt RTOS this is not possible.
We tried to put the application task where we read the interrupt register as high as possible in the task priorities levels
(at least at level 0), but thinghs do not change very much.
We’ll appreciate some help from anyone with some expirence on this matter,
thanks to everybody!
The open AT low level interrupt handler works well (it’s responsivness is claimed to be lower than 50 microsecond).
But the task where we do the reading of the spi bus is one of the application task, where the response time is about 10 milliseconds.
The spi operation cannot be done in the low level nor in the high level task context (ADL_RET_ERROR_SERVICE_LOCKED).
In the “Bus service application note” developer.sierrawireless.com/en/ … /AirPrime- Bus Services - Application Note.aspx
there is a note regarding the possibility of doing read and the write of the spi bus in low level interrupt contexts:
5.5.3 Read/Write to SPI Bus
Bus Read and write operations can be performed in two modes.
Synchronous mode: In synchronous mode, bus related operations are not allowed from low level handlers. This is
due to an ongoing bus operation.
Asynchronous mode: In this mode, the bus related operations are allowed from the low level handlers.
Should be setting the asynchronous mode a workaround to our problem?