Nested interrupt for Rx130 Controller - Part Number R5F51306B

Question

Hello, 
 
 I am using two SCI channels SCI0 and SC8 for following purpose - 
 1. SCI0 is used for serial UART communication. 
 2. SCI8 is used for serial SPI communication. 
 Both channels have their interrupts of transmit and receive configured. SCI0 i.e., UART comms having higher priority (15) than SCI8 means SPI comms (14). 
 From receive interrupt of SCI0, we are calling SPI read write to EEPROM. 
 However, in this case SPI interrupts are not getting called. 
 If I interchange priorities of SCI0 and SCI8 channels i.e., SCI0 UART comms having lower priority than SCI8 SPI comms then SPI interrupts as well as UART works for few 100 milliseconds, but after that UART frames are missed and further communication is stopped. 
 Is there anything specific configuration that needs to be done for enabling nested interrupts work in correct fashion. 
 Am I doing anything wrong? 
 
 Best Regards, 
 Satish

JanekD · Answer

the only thing you have to do is to re-enable interrupts in interrupt call using keyword 'enable' in interrupt definition. Using E2S and CCRX is this to do in 'vect.h'. 
 here an example for Rx interrupt: 
 #pragma interrupt (Excep_SCI6_RXI6(vect=86, enable))

Hossein · Answer

Hello Satish, 
 Thank you for reaching out to the Renesas community and for providing a detailed explanation of the issue. 
 As I can see from your program's structure, you're handling multiple tasks within the interrupt service routines, and each interrupt call consumes CPU cycles. Here are a few things to keep in mind: 
 As you may already know:

An SPI overrun error can occur when data is sent from the slave device (EEPROM), but the CPU fails to retrieve the data from the RDR register, causing the buffer to fill up. Since SCI only has a double buffer for data caching, it's crucial to continuously read data to prevent overruns, especially at higher baud rates.

When reading data from the SPI slave (EEPROM), it's vital to treat this as an atomic operation, ensuring that no other interrupt can access the CPU while data is being read. This prevents the CPU from becoming busy during SPI transfers and minimizes the risk of overruns.

To address these issues, consider keeping interrupt service routines as short as possible, increasing the CPU clock speed to 32MHz, and reducing the SPI baud rate. Additionally, as dear NGE suggested, you can utilize DTC for more efficient SCI communication handling, especially for frequent data transfers. 
 I encourage you to try these suggestions and assess their effectiveness. 
 If you have any further questions or need clarifications, please feel free to reach out. Happy debugging! 
 Best regards.