theficus
commented
2 years ago I did some extensive debugging into this issue this evening and I believe I understand what's going on. It appears that what is happening is when the ISR is calling into the ESP TwoWire library to read data from the I2C bus, it will ultimately fail with I2C_ERROR_BUSY and this is unrecoverable.
Digging further into this, it appears that there are some known limitations on the ESP platform specific to doing I2C operations from within an ISR due to how its FreeRTOS handles task switching. The recommendation for this seems to be to use a ESP task queue to do the work, and have the ISR simply signal the queue to do something. I played around with this some and actually made some pretty good progress.
Here's some prototype sample code (incomplete -- based on the original sample):
QueueHandle_t joyQueue;
void onButtonPress()
{
int i = 0;
xQueueSend(joyQueue, &i, portMAX_DELAY);
}
void joyTaskConsumer(void* p)
{
Serial.println("In queue!");
int element;
size_t i = 0;
while(true)
{
Serial.printf("q=%zu\n", i);
xQueueReceive(joyQueue, &element, portMAX_DELAY);
uint32_t v = 0;
v = ss.digitalReadBulk(s_button_mask);
Serial.println(v, BIN);
i++;
}
vTaskDelete(NULL);
}
void setup()
{
Serial.begin(115200);
joyQueue = xQueueCreate(10, sizeof(int));
ss.begin(0x49);
ss.pinModeBulk(s_button_mask, INPUT_PULLUP);
ss.setGPIOInterrupts(s_button_mask, true);
pinMode(JOY_IRQ_PIN, INPUT);
xTaskCreate(
joyTaskConsumer,
"JoyTaskConsumer",
10000,
NULL,
1,
NULL);
attachInterrupt(JOY_IRQ_PIN, onButtonPress, FALLING);
}This actually seems to work reasonably well -- I am seeing events fire pretty much immediately when the button is depressed and released and on every subsequent button press, and the queue task simply cedes to any other work on the CPU until something gets queued which is basically what I want. In my testing I am running into a new issue where pressing too many buttons at once or too quickly can eventually cause the ESP32 to crash which I'm still troubleshooting (I think this is due to a race with the Serial.println statement), but in all this is working a million times better than before!
It's possible I could also use a semaphore or some other similar approach to do this if I wanted to and I'll do some more experimentation. It seems like the key thing here is to keep the actual work of communicating with the I2C bus out of the ISR.
So in conclusion this seems more like an issue specific to the interrupt use case with the ESP platform rather than a simple bug or PEBKAC problem. This would probably be something useful to call out in the docs or samples as this is something that can come as quite a shock to someone who's trying to use interrupts but is new to the ESP platform.
Further reading:
ladyada
I have also posted about this on the Adafruit forums but haven't received any response. After doing extensive investigations on this I'm pretty confident this isn't a simple PEBKAC issue but I'm unsure if it's a hardware issue, library issue, or something else I'm missing.
Hardware:
Scenario: I am trying to use an interrupt to respond to button presses from the Joy Featherwing without needing to monitor the button state in a loop.
I'm seeing two suspicious behaviors:
The only way I seem to be able to actually read the state of the Joy Featherwing is from within the main execution loop, which is exactly what I'm trying to avoid.
Here is some sample code:
For extra debugging, I have built with
-DSEESAW_I2C_DEBUG.Here's the output when I run the program:
Note that the initial read that happens in setup() shows the expected value. The subsequent read that happens from within the ISR after pressing a button (the final line) shows 0. The ISR fires once, and only once from button presses; any subsequent button presses are ignored. I've further confirmed that the ISR will fire if I short GPIO 14 to + so the ISR should in theory be fine.
I'm guessing at this point the issue has something to do with the ISR context trying to read Seesaw state and something internally not being as expected. The Seesaw API documentation notes that interrupts won't clear until code reads the state, and the fact that the interrupt fires once and only once and doesn't get any result back makes me assume that there's no read actually happening and the internal state doesn't clear. This theory is further bolstered by the debug logging that shows the initial read from setup() getting 4 bytes back while the subsequent read from within the ISR logs nothing.