ADC periodic framework produces multiple consecutive callbacks at 75KHz in S1JA



We have been using the ADC periodic framework in the S3A6 to sample channels 2 and 3 with the following configuration:

  • Period Value & Unit: 75KHz
  • Length of data buffer: 200
  • Sampling iterations: 50


The project also includes a console framework over USB.

We run several tests and the project seemed to work OK (the values on the buffer were correct, the callback was called at the appropriate intervals, etc.)

However, we had to port the project to a S1JA platform and the callback started showing a strange behavior: instead in a single callback, consecutive callbacks were produced by the periodic framework (see picture).


Other information that may be relevant:



Any clues?

  • Hi Jorge,

    How's this issue? Were you able to find out why the project doesn't seem to work well with the S1JA device?

    RenesasRulz Forum Moderator

  • In reply to JB:



    No, sadly we have not figure out the problem.


    We have a theory, though (take into account that we have not be able to verify it): each time the DTC transmits the number of “sample count” blocks, an adc interrupt is generated, which is handled by the adc_periodic driver in order to reset the DTC. The DTC reset function disables the DTC, modifies some variables, and enables the DTC again. Out theory is that a new adc scan finishes just before or during the DTC reset, which results in an adc interrupt that is not caught by the DTC and, thus, is handled by the adc interrupt handler, i.e., it is interpreted as another DTC transmission of “sample count” blocks.


    As another note, we believe that if an adc scan finishes before the DTC reset is performed, this will result in an adc scan lost. If this happens before the data buffer end has been reached, the adc scan will be erased by the first write after the reset BUT, if this happens at the end of the data buffer, the adc scan will be written out of the data buffer (due to the automatic index increment) resulting in an “out of bounds” error.



    In summary, we believe these issues are related to the high scan frequency we are using (75KHz, 13.3us per scan) and that we may have reached a limitation of the adc_periodic driver. We did not find a workaround, so we ended implementing our own “adc_periodic”.



    I hope this information is useful for someone, even if it is to disprove it. After all, it seemed to work well on the S3A6.



    Kind Regards,