Open amoldeshpande opened 2 months ago
Have you tried leaving intr_type at default (no interrupt), then add the handler using gpio_isr_handler_add() before calling gpio_set_intr_type() at the end?
tried that out just now. Didn't change anything.
Oh, and if you have a level interrupt it will fire again as soon as the handler is left. This triggers the watchdog. Try an edge interrupt.
I see. That's probably what it is.
I tried ANYEDGE and RISING and FALLING, but they didn't trigger the ISR, so I was trying out LOW_LEVEL.
Those others would be edge-triggered, right ?
Hello @amoldeshpande ,
As @kriegste said, the issue is that the CPU enters your GPIO ISR handler again and again since the level of your GPIO has not been changed. What you want to do in your ISR is to make sure your device doesn't assert the GPIO anymore and according to the CC1101 datasheet, it depends on how you configured it.
For example, if the device's GDOx_CFG
register is set to 0
, then you get an interrupt when the RX FIFO size has reached its "full" threshold. In that case, you should trigger a transfer from the ESP32 to your device to let the latter empty its RX FIFO (According to the datasheet: De-asserts when RX FIFO is drained below the same threshold.
)
If there is another way (faster?) to let the device de-assert its GPIO while you could defer the transfer to a Task, it would be even better if the serial communication between the ESP32 and CC1101 is slow.
so, I am not using the FIFOs of the CC1101. I'm trying to use the "Asynchronous serial mode", where the data is delivered through GDO2 .
Maybe I'm misunderstanding how interrupts work in this case, but I would have expected that if I set the interrupt type in ESP-IDF to "ANYEDGE", I should get an interrupt for each time the radio sends a bit.
Please note that at this time the radio is not even transmitting. So I don't know where the spurious interrupts are coming from. It's not just for LOW-type interrupts. HIGH also has the same crash. I don't understand why there is even an interrupt in this case.
Obviously, I'm new to esp32 and ESP-IDF, so I must be doing something wrong. I only wish I knew what it was :-)
Anyway, I might try Arduino ESP next since there is example code out there that does exactly what I need.
For example, in this code at https://github.com/rstrouse/ESPSomfy-RTS/blob/main/Somfy.cpp
if(this->config.enabled) {
rxmode = 1;
pinMode(this->config.RXPin, INPUT);
interruptPin = digitalPinToInterrupt(this->config.RXPin);
ELECHOUSE_cc1101.SetRx();
//attachInterrupt(interruptPin, handleReceive, FALLING);
attachInterrupt(interruptPin, handleReceive, CHANGE);
Serial.printf("Enabled receive on Pin #%d Timing: %ld\n", this->config.RXPin, millis() - timing);
}
This software works just fine when I flash it to my esp32, so it's not my hardware that is faulty.
Answers checklist.
IDF version.
ESP-IDF-v5.3.0
Espressif SoC revision.
esp32-32S WROOM
Operating System used.
Windows
How did you build your project?
VS Code IDE
If you are using Windows, please specify command line type.
PowerShell
Development Kit.
ESP32 WROOM 32S
Power Supply used.
USB
What is the expected behavior?
should not crash
What is the actual behavior?
crashes with WDT error even with empty ISR
Steps to reproduce.
I am trying to get a CC1101 chip working with an ESP32. Using ESP-IDF plugin for VsCode.
gpio setup:
ISR:
Please note that every single line in the ISR is commented out.
The problem I was actually trying to solve is that I am not able to get any interrupts at all, even though I'm fairly certain the CC1101 is set up correctly.
In playing with various interrupt types, I finally tried LOW_LEVEL and hit this crash every time I run the code.
Any ideas ?
Debug Logs.
No response
More Information.
No response