먼저 어떤 GPIO 를 사용하셨는지,

해당 시간은 어디에서 측정하신 것인지, 그 신뢰성은 믿을만한 것인지, 

GPIO 의 인터럽트 핸들러는 어떻게 처리하셨는지,

인터럽트 핸들러에서 얼마만큼의 시간을 소비하는지,

다른 인터럽트 처리 루틴에서 시간 지연은 없는지를 알아야겠죠

30번이면 33.3ms 입니다.

다른 것은 아무것도 하지 않고 해당 인터럽트 수신만 하는 데도 못받는다면 문제가 있겠죠.

하지만 다른 요소들이 첨가되는 순간부터 문제가 발생할 가능성이 생깁니다.

일단은 다른 모든 요소를 제거하고도 인터럽트를 못 받는 다면 측정 결과의 신뢰성도 생각해야합니다.

인터럽트를 하나씩 놓치는 경우 얼마만큼의 빈도로 해당 문제가 발생하는지의 시간이

다른 무언가의 시간과 연관이 있을수도 있습니다.

MCU 에서 하드웨어적으로 인터럽트를 받지 못하는 경우는 절대 없습니다. 

(결코 이런일은 일어나지 안습니다. 소프트웨어 입장에서 보면 컴파일러를 못밎는 경우죠)

다른 프로그램 전혀 안돌리고 인터럽트 모듈만 올려서 인터럽트 되는 것만 확인한 것입니다.

참고로 GPN 9번입니다.

프로그램 내용은 아래와 같습니다.

static struct timeval g_ota = {0, 0}; 

static irqreturn_t sa_irq_interrupt(int irq, void *dev_id, struct pt_regs *regs)
{
 long diff;
 struct timeval t = {0, 0};

 unsigned long flags;
 local_irq_save(flags);
 local_irq_disable( );
 do_gettimeofday(&t);

 diff = difftimeval(g_ota.tv_sec,g_ota.tv_usec,t.tv_sec,t.tv_usec);
 g_ota = t;
 if (irq == sa_irq_num) {
  printk("$$ [%06lu %06lu] [%06lu]\n",t.tv_sec, t.tv_usec,diff);
 }
 local_irq_restore(flags);
 return IRQ_HANDLED;
}

static int __init nano_sa_gpio_init(void)

{

  ......

 set_irq_type(sa_irq_num,IRQ_TYPE_EDGE_RISING);
 if(request_irq(sa_irq_num, (irq_handler_t)sa_irq_interrupt, IRQF_DISABLED, "SA_GPIO", NULL))
   .....

}

조금 힘든 방법이기는 해도 확실하게 확인하는 것이 좋겠죠.

스코프를 이용해서 인터럽트 파형을 확인해 보셨나요?

일단  gpio 하나를 트리거로 사용하게 하고 위의 인터럽트 구간에서

시간 지연이 40ms 이상이면 트리거 출력을 내보내서 스코프에서 홀드하게 하시면

해당 시간을 전후로 입력을 잡을수 있을 겁니다.

하드웨어적인 타이밍을 먼저 검증하시면 어떨까요?