Hi. I have both an M5StackS3-SE and a LoRa868 V1.1 in a stack. I wrote a driver for the sx127x that fits my needs. I have WiFi, AWS IoT connectivity, and the sx127x working perfectly. I recently decided to try to get the display working so I could put together a simple LVGL application to display some metrics.

I decided to use the BSP component for the M5Stack CoreS3 located here: https://github.com/espressif/esp-bsp/tree/master/bsp/m5stack_core_s3. It's pretty straight forward to consume the component and initialize the BSP. When I do this, I see that it initializes the SPI Master controller itself (HOST2), which is not a problem, in theory. The LoRa radio communicates over the same SPI lines (MISO, MOSI, and SCK). I made sure to select a Chip Select line that does not conflict with anything else (DIP switches on the LoRa radio stack).

I am not able to get the LoRa radio to work when I initialize the display. I can get the display to work and render one of the LVGL demos without a problem, but I am not able to also communicate with the LoRa radio at the same time. I should be able to as the ESP SPI Master controller driver should handle multiple drivers utilizing the same SPI configuration with different chip select lines.

Here's my DIP switch config for the LoRa radio:

• NSS = G6 (BUS_G6 on the schematic, straight to header)
• IRQ = G10 (BUS_ADC1 on the schematic, straight to header)
• RST = G7 (BUS_G7 on the schematic, straight to header)

This is how I setup the SPI device using the SPI driver:

// Configure SPI bus
spi_device_interface_config_t spi_dev_cfg = {
    .clock_speed_hz = 9000000,  // 9MHz
    .mode = 0,
    .spics_io_num = hw_config->cs_gpio,
    .queue_size = 7,
    .flags = 0,
    .pre_cb = NULL
};
ret = spi_bus_add_device(spi_host, &spi_dev_cfg, &device->spi);
if (ret != ESP_OK) {
    ESP_LOGE(TAG, "Failed to add SPI device");
    // .. some error handling here ...
    return NULL;
}

I confirmed in the BSP implementation that the SPI master controller appears to be initialized correctly (https://github.com/espressif/esp-bsp/blob/master/bsp/m5stack_core_s3/m5stack_core_s3.c#L173).

It appears the DC (Data/Command) line for the LCD controller is also connected to the same MISO pin as configured by the documentation and the BSP implementation (https://github.com/espressif/esp-bsp/blob/master/bsp/m5stack_core_s3/include/bsp/m5stack_core_s3.h#L63C9-L63C19). I am not sure if this could cause problems.

I am likely overlooking the issue here. I hope it's just a silly mistake on my side. I am hoping someone perhaps knows what is going on here and can point me in the right direction.

Many thanks in advance!

@felmue Thank you for the pointer! Looks like perhaps it's fixed for the Arduino implementation? It does not seem fixed for the ESP-IDF version quite yet. Your workaround combined with the pre_cb and post_cb callbacks worked! Here's a snippet/summary of what I did:

#ifdef CONFIG_M5CORES3_SPI_CONFLICT_FIX
#define M5CORES3_SPI_CONFIG_FIX_MISO_PIN 35

void sx127x_spi_pre_transfer_m5cores3_fix_callback(spi_transaction_t* t) {
    // before a SPI transaction is started, we need to change the driving direction
    // of the DC pin in the CoreS3 (the CoreS3 uses the MISO pin as the DC pin and 
    // configures it as an output ping which conflicts with other SPI devices on the bus)
    
    // set gpio direction for MISO pin to input
    gpio_set_direction(M5CORES3_SPI_CONFIG_FIX_MISO_PIN, GPIO_MODE_INPUT);
}

void sx127x_spi_post_transfer_m5cores3_fix_callback(spi_transaction_t* t) {
    // undo pin direction change after SPI transaction is done

    // set gpio direction for MISO pin back to output
    gpio_set_direction(M5CORES3_SPI_CONFIG_FIX_MISO_PIN, GPIO_MODE_OUTPUT);
}
#endif

sx127x_handle_t sx127x_init(const sx127x_modem_config_t* modem_config)
{
    // ...

    // Configure SPI device
    spi_device_interface_config_t spi_dev_cfg = {
        .clock_speed_hz = 9000000,  // 9MHz
        .mode = 0,
        .spics_io_num = modem_config->cs_gpio,
        .queue_size = 7,
        .flags = 0,
        #ifdef CONFIG_M5CORES3_SPI_CONFLICT_FIX
        .pre_cb = sx127x_spi_pre_transfer_m5cores3_fix_callback,
        .post_cb = sx127x_spi_post_transfer_m5cores3_fix_callback
        #endif
    };
    ret = spi_bus_add_device(spi_host, &spi_dev_cfg, &device->spi);
    if (ret != ESP_OK) {
        ESP_LOGE(TAG, "Failed to add SPI device");
        vSemaphoreDelete(device->spi_mutex);
        free(device);
        return NULL;
    }

    // ...
}

I can now use both the display and the sx1276 at the same time on the M5Stack CoreS3.

Thanks again for your assistance!

@felmue Thanks a ton for that pointer! That looks promising. A bit unfortunate it was designed this way if that workaround is the only way. The official M5Stack CoreS3 BSP also has a warning that says that the SD Card does not work and they are working on fixing it. I wonder if the issue is similar to this. I am going to try to implement this and report back.

In ESP-IDF there is a pre_cb and post_cb (callback configurations) that can be configured with the SPI device when it's registered on the bus. This should allow me to accommodate the DC/MISO reconfiguration in a bit more automated of a way.

Thanks again for your help!

Hi. I have both an M5StackS3-SE and a LoRa868 V1.1 in a stack. I wrote a driver for the sx127x that fits my needs. I have WiFi, AWS IoT connectivity, and the sx127x working perfectly. I recently decided to try to get the display working so I could put together a simple LVGL application to display some metrics.

I decided to use the BSP component for the M5Stack CoreS3 located here: https://github.com/espressif/esp-bsp/tree/master/bsp/m5stack_core_s3. It's pretty straight forward to consume the component and initialize the BSP. When I do this, I see that it initializes the SPI Master controller itself (HOST2), which is not a problem, in theory. The LoRa radio communicates over the same SPI lines (MISO, MOSI, and SCK). I made sure to select a Chip Select line that does not conflict with anything else (DIP switches on the LoRa radio stack).

I am not able to get the LoRa radio to work when I initialize the display. I can get the display to work and render one of the LVGL demos without a problem, but I am not able to also communicate with the LoRa radio at the same time. I should be able to as the ESP SPI Master controller driver should handle multiple drivers utilizing the same SPI configuration with different chip select lines.

Here's my DIP switch config for the LoRa radio:

• NSS = G6 (BUS_G6 on the schematic, straight to header)
• IRQ = G10 (BUS_ADC1 on the schematic, straight to header)
• RST = G7 (BUS_G7 on the schematic, straight to header)

This is how I setup the SPI device using the SPI driver:

// Configure SPI bus
spi_device_interface_config_t spi_dev_cfg = {
    .clock_speed_hz = 9000000,  // 9MHz
    .mode = 0,
    .spics_io_num = hw_config->cs_gpio,
    .queue_size = 7,
    .flags = 0,
    .pre_cb = NULL
};
ret = spi_bus_add_device(spi_host, &spi_dev_cfg, &device->spi);
if (ret != ESP_OK) {
    ESP_LOGE(TAG, "Failed to add SPI device");
    // .. some error handling here ...
    return NULL;
}

I confirmed in the BSP implementation that the SPI master controller appears to be initialized correctly (https://github.com/espressif/esp-bsp/blob/master/bsp/m5stack_core_s3/m5stack_core_s3.c#L173).

It appears the DC (Data/Command) line for the LCD controller is also connected to the same MISO pin as configured by the documentation and the BSP implementation (https://github.com/espressif/esp-bsp/blob/master/bsp/m5stack_core_s3/include/bsp/m5stack_core_s3.h#L63C9-L63C19). I am not sure if this could cause problems.

I am likely overlooking the issue here. I hope it's just a silly mistake on my side. I am hoping someone perhaps knows what is going on here and can point me in the right direction.

Many thanks in advance!