ESP32 Forum

Hi,

Can any of you "experts" help out on this issue.

I'm running an ESP32 NodeMCU with LoRa module (RFM95W) and an ILI9488 display.
The libraries I'm using can be found here:
https://github.com/sandeepmistry/arduino-LoRa
https://github.com/Bodmer/TFT_eSPI

I'm using the recommended default GPIO's for the LoRa module as these seem to work best with the display and sharing the same SPI bus with the display.

GPIO's used for LoRa:
// LoRa setup using default GPIO's
#define SCK_GPIO5 5
#define MISO_GPIO19 19
#define MOSI_GPIO27 27
#define SS_GPIO18 18
#define RST_GPIO14 14
#define DI0_GPIO26 26
#define LoRa_BAND 868E6

GPIO's used for TFT:
#define TFT_SCLK 5
#define TFT_MISO 19 // ILI9488 - connect T_D0 but leave TFT MISO disconnected if other SPI devices share MISO
#define TFT_MOSI 27
#define TFT_CS 15
#define TFT_DC 2
#define TFT_RST 4
#define TOUCH_CS 0 // Chip select pin (T_CS) of touch screen

Everything works fine and as expected and LoRa packets are received OK if running on just one core of the ESP32 (tested in excess of 20 hours).

Compiling the same code to run on both cores with LoRa on core 0 and the TFT on core 1, I am experiencing problems.
The first LoRa packet is normally received OK but then all other packets are either corrupt, not received, or anything other than the packets sent (output to serial monitor).
Further, after the first packet is received LoRa.parsePacket() never returns any positive value and LoRa.read() never gets called.

I've run with TFT's ILI9341 and ILI9488 but always the same problem when running dual core.

Really need help in solving this issue. Might be something simple for you "experts" but I'm pulling my hair out trying to find a solution !!

Thanks in advance for any help and advice.

Regards.

Hard to say without seeing the code. In general: Smells like a threading problem, where some functions (the SPI driver ones, maybe?) aren't re-entrant. Do you have the same issue when you use two threads, but on the same core and with the same priority?

It seems to me that sharing hardware pins between the two cores is inviting disaster. Either you need to use semaphore locks or use totally separate pins. The access to the display is probably synchronous and manageable (if data transfers are kept small). Since the LoRa code is probably interrupt driven there is very little you can do to control timing with respect to display transfers.

I highly recommend separating into two separate SPI busses.

The ESP32 Arduino SPI library has an example using two different SPI busses: SPI_Multiple_Buses.ino and you can easily remap the IO pins on those SPI devices to any other unused GPIO.

Hi ESP_Sprite,

Many many thanks for your response - I've now got it working with your advice !!

This is what I've done:
Kept the same GPIO's as previously (LoRa default) as the LoRa module has problems starting if other GPIO's are used.
Set up the two tasks to run using two threads and assigned them to both run on core 1.
Set priority of the TFT task to 1 and the LoRa task to 2 (with the same priority it doesn't work).

Currently the program has been running for several hours now and approaching over 5500 packets received with no drop-out !!
With the new setup, packets are being received (and processed) in less than a second - incredible !!

My conclusions:
It is imperative to use the default GPIO's for the LoRa RFM95W module viz:
GPIO5 -- SX1278's SCK
GPIO19 -- SX1278's MISO
GPIO27 -- SX1278's MOSI
GPIO18 -- SX1278's CS
GPIO14 -- SX1278's RESET
GPIO26 -- SX1278's IRQ (Interrupt Request)

Share the same SPI bus with the ILI9488 display otherwise it doesn't work (MISO is not connected on TFT as per Bodmer's advice - TFT_eSPI library).
HSPI cannot be used with TFT_eSPI library as LoRa uses GPIO 14 for it's RESET - changing this pin then LoRa module will not start.

As you mention, it seems to be a threading problem. I'll test further to see if the same configuration works running on both cores.

Encore, thankyou, thankyou, thankyou - I can now stop pulling my hair out - I'm almost bald with this issue !!

Kind regards.

FLYINGSCOT wrote: ↑

Tue Sep 24, 2019 1:48 pm

It is imperative to use the default GPIO's for the LoRa RFM95W module viz:
GPIO5 -- SX1278's SCK
GPIO19 -- SX1278's MISO
GPIO27 -- SX1278's MOSI
GPIO18 -- SX1278's CS
GPIO14 -- SX1278's RESET
GPIO26 -- SX1278's IRQ (Interrupt Request)
HSPI cannot be used with TFT_eSPI library as LoRa uses GPIO 14 for it's RESET - changing this pin then LoRa module will not start.

You can't move the SX1278 RESET to another GPIO? It seems to me that this would be relatively easy since the RESET pin is probably only pulsed once on start up so it shouldn't be a signal integrity issue.

If that doesn't work, you can easily reassign the HSPI pins to almost any other GPIOs. Even reassigning just SCLK would eliminate the hardware contention as in:

Hi TomWS1,

Thanks for your input. I tried assigning the Reset to another GPIO to free-up GPIO 14 for HSPI but, as mentioned in my post, LoRa fails to start. Why, I don't know. I'm also stuck to assign HSPI to other GPIO's because not only do I have LoRa and the TFT display, but also connected is a GPS on GPIO's 16 & 17, a MS5611 barometer on GPIO's 21 & 22, a MOSFET using GPIO 33, an LED using GPIO 32 and a buzzer using GPIO 25. So, my options are very limited. BTW the issue was with a "basic" program without the GPS, baro etc. etc. being configured so none of these interacted to cause the problems. I agree, your suggestions are the most easy to implement but, alas, I couldn't get them to work. Thanks anyway.

Regards.