Replies: 1 comment 1 reply
-
|
The debug mode shows that the SPI is continuously reading out 0xFF bytes - that is a typical behavior of incorrectly set pins or a bad connection. If you have an oscilloscope or a logic analyzer, you can check data is being at least sent out from the ESP32 correctly, that will rule out an issue with the SPI configuration. Since 0xFF is all bits set to logic 1, I would look into issues with the chip select pin first. |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Good morning,
I am trying to get an ESP32-P4 to communicate with a SX1262 LoRa module over SPI. The radio refuses to wake up, the BUSY line stays permanently high, and I am receiving a -2 (RADIOLIB_ERR_CHIP_NOT_FOUND) error from RadioLib.
I have done extensive hardware and software debugging (including DMA memory alignment, checking power domains, and verifying signals) but the module remains unresponsive. I have looked over the datasheets and technical reference manuals for potential GPIO conflicts, but that did not help.
I would greatly appreciate any possible guidance and help on this issue.
Hardware Setup
MCU: Waveshare ESP32-P4-Module-DEV-KIT
LoRa Module: Waveshare SX1262 LoRa Module (Sub-GHz)
Framework: ESP-IDF v5.5.2-729
Library: RadioLib (with a custom EspHal.h)
Pin Config
constexpr gpio_num_t LORA_CS = GPIO_NUM_1;
constexpr gpio_num_t LORA_SCK = GPIO_NUM_22;
constexpr gpio_num_t LORA_MOSI = GPIO_NUM_21;
constexpr gpio_num_t LORA_MISO = GPIO_NUM_33;
constexpr gpio_num_t LORA_RST = GPIO_NUM_20;
constexpr gpio_num_t LORA_BUSY = GPIO_NUM_32;
constexpr gpio_num_t LORA_DIO1 = GPIO_NUM_53;
constexpr gpio_num_t LORA_RXEN = GPIO_NUM_48;
constexpr gpio_num_t LORA_TXEN = GPIO_NUM_54;
Error Messages
Code:
EspHal.h
Beta Was this translation helpful? Give feedback.
All reactions