Hi Everyone,

I am running SPI transactions in an ISR of a GPT timer.  The timer is firing at 48 kHz.  SPI transactions are used to sample output of an ADC.  SPI module is configured as:

  • master
  • mode fault error: disable
  • bitrate: 5000000
  • bit rate modulation: disable
  • all interrupts set to priority 1
  • PCLKA: 120 MHz

GPT timer is configured as:

  • Periodic 48 kHz
  • overflow interrupt priority set to 1

Each transfer reads 16 bits and takes about 9.5 usec form start to finish (i.e. CS enabled in the GPT ISR, SPI transaction started in the ISR, CS disabled in the SPI callback function).  GPT period is 20.83 usec so there is plenty of time for each transaction to finish before the GPT fires again.  After each SPI transaction is started, an SPI callback writes data to a local buffer.  Every now and then, SPI callback is called with p_args->event set to SPI_EVENT_ERR_OVERRUN.  The next call to the writeRead() API returns SSP_SUCCESS but the SPI callback is never called again.  All subsequent calls to writeRead() return SSP_ERR_HW_LOCKED which is not surprising.

Sometimes this takes 5 minutes, sometimes a half hour.  But the error always seems to happen.  I tried to run with DTC drivers removed but that didn't help.  I also tried to enable bit rate modulation and mode fault error but again with no luck.  Is there a way to clear the error?  Would anyone know what could be causing this behavior with configuration as shown above?

I appreciate any help.



  • Thank you for posting your application problem in e2 studio. This is no e2 studio problem and it has nothing to do with e2 studio.
    You don't say which processor you use. I guess this could be a RX65x.
    The problem looks like a system where either too long interrupt routines or too many interrupt routines generate a system load of slightly more than 100%. This over time delays the interrupt routine for your CSI . In the end it cannot serve all interrupts and gets an overrun error.
    Possible solutions:
    - Reduce number of interrupts.
    - Allow interrupt nesting with CSI interrupt as a higher priority interrupt.
    - Check execution time of interrupt routines.
    - Improve code execution time by increasing compiler optimization with focus on execution speed.
    - Depending on the compiler being used it may also help to switch to another compiler.
  • In reply to FrankL:

    Hi Frank,

    sorry about the post. I thought I had the right forum. I'll move my post to the correct one. In the meantime, thank you or providing a list of possible solutions.

  • Hi Paul,

    I'm going to archive this post since this was posted in the Synergy group already. Thanks!

    RenesasRulz Forum Moderator