Closed lukecyca closed 5 years ago
I agree with your analysis: It seems to be SPI related and it's likely a timing issue and not a wiring issue (otherwise 0xff
would be returned).
I propose you experiment with the SPI parameters. In hal_spi_init()
in hal_esp32.c
you can make the following changes:
cs_ena_posttrans
line (see below). It has helped in a previous project.mode
to 1, 2 or 3The relevant code is:
spi_device_interface_config_t spi_device_intf_config = {
.mode = 0,
.clock_speed_hz = CONFIG_TTN_SPI_FREQ,
.command_bits = 0,
.address_bits = 8,
.spics_io_num = lmic_pins.nss,
.queue_size = SPI_QUEUE_SIZE,
.cs_ena_posttrans = 2
};
Do you happen to have a DSO? If so, try to capture the SPI communication and attach it to the issue. It would be very helpful.
Thanks - mode = 1
worked!
It's a bit surprising that mode = 1
works. The datasheet clearly specifies mode 0.
Today I've tested it with a RFM95W module (the green module on your Adafruit board) and did't have any problems with the unmodified software.
Most likely, the level converter / buffer chip on the Adafruit board change the timing. So I've ordered the Adafruit board and will test it myself. I'll try to find a setup that works with as many boards as possible.
In the mean time, I've changed the SPI mode to 1 (see 5cd2c7b) even though the SX1276 data sheet clearly states the SPI mode to be CPOL = 0 and CPHA = 0 (equivalent to mode 0).
However, another boards revealed the same problem with a particular pin configuration. Changing to mode 1 fixed it as well. I have now received the Adafruit breakout board it works with mode 1 as you have already discovered. Furthermore, it works with all other boards I have.
I'm using a regular ESP32 along with this RFM9x module.
https://learn.adafruit.com/adafruit-rfm69hcw-and-rfm96-rfm95-rfm98-lora-packet-padio-breakouts/pinouts#spi-logic-pins-2-6
I've hooked it up such that the pins are connected to the following pins on the module:
However, it fails at
radio.c:739
. I instrumented the code and found that theRegVersion
returned is0x9
(0b1001) instead of the expected0x12
(0b10010). Given the similar-but-shifted binary representations, I suspect a timing/sync problem on the bus.Any ideas?