XIAO ESP32-S3 Interrupts on D5 and D6

Products & Technology XIAO
#1

Good day all.
I am currently debugging some hardware which has been built by a student.
I am writing the code. The hardware has D5 and D6 as set as inputs with pull up enabled, no external resistors.

pinMode(D5, INPUT_PULLUP);
pinMode(D6, INPUT_PULLUP);

D5 and D6 monitor to signal lines, each driven by an optocoupler.
D5 and D6 are each attached to interrupts.

attachInterrupt(D5, d5ISR, RISING);
attachInterrupt(D6, d6ISR, FALLING);

Each ISR handles the interrupts as normal, routine for D5 shown, d5Flag is a defined as bool.
The counter (uint32_t d5Counter = 0;) simply keeps track of the number of events…

void IRAM_ATTR d5ISR()
{
  d5Flag = true;
  d5Counter++;
}

What I find is that for each triggered event, when the counts are read back, the counts are increment by large amounts, varying from 100s to 1000s, all depending on the period between each interrupt event.
The edge inputs to D5 and D6 are clean and fast. No noise.

This has got me stumped. Are there any caveats in using these pins for interrupts. If so, I will have to modify the PCBs.

Regards and thanks.

#2

Hi there,
Can you try using the GPIO pin numbers instead?
give it a go,
HTH
GL :slight_smile: PJ
ie. GPIO (06), GPIO (43)

2
21485×1255 82.3 KB

#3

I’ll try your suggestion later today.
To confirm pin functions as D5 and D6, I placed a normal switch to ground and tested with a basic

digitalRead(D5);

operation, and this worked as expected for the definition, same for D6.
Cheers.

#4

I believe that I have solved the problem.

Changing the D5 and D6 definitions to GPIO definitions did NOT solve the issues at hand.
I systematically shut down other modules that were running to try to isolate the cause.

Nothing was resolved until I turned off in code the HTTP requests, effectively shutting down the periodic 5 second WiFi activities. No HTTP requests, no extraneous IRQ events.

Further tests and with the use of a DSO, I found that the WiFi bursts were creating a multitude of IRQ events, quite possibly due to the weak on chip PULL_UP resistors not being able to withstand the induced interference from the WiFi signal. The 5V and 3V3 supply rails all appear to be clean, as they have additional filtering added on the PCB.

Must admit, this is the first time I have ever seen this happen. The board will be modified tomorrow with the addition of strong PULL_UP resistors being fitted, plus some signal filtering added to the opto isolators outputs.

Cheers.

1 Like