DSPI Communication timeout issue

[bharathn3402]

I am using the MPC5775B microcontroller with an SPI EEPROM. In my application, CAN messages are received continuously using interrupts, and SPI communication with the EEPROM is also interrupt-driven.

Under heavy CAN bus traffic (e.g., five CAN IDs are received every 1 ms), any EEPROM read operation starts timing out. I am using the DSPI_MasterTransferBlocking() API with a timeout of 10 ms. I also tried increasing the timeout value significantly, but the read operation still fails.

Interestingly, the behavior depends on the amount of data being read. When I attempt to read only a few bytes from the EEPROM, the SPI transfer times out. However, when I read an entire EEPROM page (256 bytes), the read operation completes successfully.

I also observed that if CAN traffic is stopped, the EEPROM read operation succeeds without any issues. I verified the interrupt priorities, and both the CAN and SPI interrupts are configured with the same priority level (priority 0).

I would like to understand:

• Why do small SPI EEPROM read operations time out under heavy CAN interrupt load, while larger (256-byte) page reads complete successfully?

• Could this be related to interrupt starvation, the implementation of DSPI_MasterTransferBlocking(), or the interaction between the CAN and DSPI interrupt handlers?

• Is there any known limitation or recommended configuration for using interrupt-driven DSPI transfers concurrently with high-frequency CAN interrupts on the MPC5775B?

Additionally i debugged the issue by placing break points inside the DSPI_MasterTransferBlocking(),during the debug 

status_t DSPI_MasterTransferBlocking(dspi_instance_t instance,
const void * sendBuffer,
void * receiveBuffer,
uint16_t frames,
uint32_t timeout)
{
DEV_ASSERT((uint32_t)instance < (SPI_INSTANCE_COUNT + DSPI_INSTANCE_COUNT));

status_t status;
dspi_state_t * state = DSPI_state[instance];

if (state->status == DSPI_IN_PROGRESS)
{
return STATUS_BUSY;
}

state->isBlocking = true;
(void)OSIF_SemaWait(&(state->dspiSemaphore), 0);
status = DSPI_MasterTransfer(instance, sendBuffer, receiveBuffer, frames);
if (status == STATUS_SUCCESS)
{
status = OSIF_SemaWait(&(state->dspiSemaphore), timeout);
if (status != STATUS_SUCCESS)
{
(void)DSPI_AbortTransfer(instance);
state->status = DSPI_TRANSFER_FAIL;

return status;
}
}

return STATUS_SUCCESS;
}

dspi transfer status getting success, but "OSIF_SemaWait" after dspi transfer getting timeout.

[petervlna]

Hello,

Based on the description, the DSPI transfer itself appears to be started successfully, because DSPI_MasterTransfer() returns STATUS_SUCCESS. The timeout occurs later while DSPI_MasterTransferBlocking() is waiting on OSIF_SemaWait() for the transfer-complete notification.

Therefore, this symptom is more likely related to the interrupt/completion handling path than to a basic DSPI start failure. In the blocking DSPI API, the transfer is started and the caller waits until the DSPI interrupt/callback path releases the semaphore. If the semaphore is not released before the timeout expires, the API reports timeout and aborts the transfer.

The fact that the issue appears only under heavy CAN interrupt load is an important clue. If CAN and DSPI interrupts are configured with the same priority, continuous CAN interrupt activity can delay DSPI interrupt servicing. For short EEPROM reads, the DSPI transaction completes very quickly, so the final DSPI interrupt and semaphore release are timing-sensitive. A longer 256-byte page read keeps the DSPI transaction active for longer and may allow the driver’s interrupt handling path to progress differently, which can explain why the larger transfer completes while the short transfer times out.

Recommended checks:

1. Configure the DSPI interrupt with higher priority than the CAN RX interrupt and repeat the test.
2. Keep the CAN ISR as short as possible. Move CAN frame processing out of the ISR into a task/main-loop context if possible.
3. Verify that the DSPI ISR is entered in the failing case.
4. Verify that the DSPI transfer-complete callback or completion path releases state->dspiSemaphore.
5. Toggle GPIOs or use trace points in:
   1. CAN RX ISR entry/exit
   2. DSPI ISR entry/exit
   3. DSPI transfer-complete callback
   4. before and after OSIF_SemaWait()
6. Check that the blocking DSPI API is not called from an ISR or from any context where the DSPI interrupt cannot run.
7. As a diagnostic experiment, try a polling-based DSPI transfer or DMA-based DSPI transfer. If polling/DMA works under the same CAN load, it further supports that the issue is in interrupt scheduling/completion handling rather than in the SPI bus itself.
8. For EEPROM accesses, also confirm that the small-read sequence keeps the required command/address/dummy/read phase and chip-select behavior according to the EEPROM protocol. However, since the failure is reported at the semaphore wait, the first focus should be the DSPI completion interrupt path.

In summary, the most likely direction is interrupt starvation or missed/delayed DSPI completion handling under high CAN interrupt load. The first practical test should be to raise the DSPI interrupt priority above CAN and instrument whether the DSPI ISR/callback posts the semaphore in the failing case.

Best regards,

Peter