stm32F4 SDIO+ESP32 FG

[legendss13]

Hello: I have successfully run through the ESP32-SDIO-AT firmware using the SDIO interface (4 wires) in stm32, but the data transfer speed of the AT command is too slow, and sometimes I need to transfer 300k data. Therefore, I want to use the hostedfg solution, but there is little relevant information and I don't know how to start, so there are currently two questions:

1. Do I need to modify my hardware circuit?
2. Where do I need to port the STM32 software?

In addition, the firmware of ESP32 has been compiled according to the instructions in the documentation, and below is the log on the ESP32 side： bootloader I (30) boot: compile time Feb 27 2024 16:34:42 I (30) boot: Multicore bootloader I (35) boot: chip revision: v1.1 I (39) boot.esp32: SPI Speed : 40MHz I (43) boot.esp32: SPI Mode : DIO I (48) boot.esp32: SPI Flash Size : 4MB I (52) boot: Enabling RNG early entropy source... I (5 [13:31:00.341]收←◆8) boot: Partition Table: I (61) boot: ## Label Usage Type ST Offset Length I (69) boot: 0 nvs WiFi data 01 02 00009000 00004000 I (76) boot: 1 otadata OTA data 01 00 0000d000 00002000 I (83) boot: 2 phy_init RF data 01 01 0000f000 00001000 I (91) boot: 3 factory factory app 00 00 00010000 00100000 I (98) boot: 4 ota_0 OTA app 00 10 00110000 00100000 I (106) boot: 5 ota_1 OTA app 00 11 00210000 00100000 I (113) boot: End of partition table I (118) boot: Defaulting to factory image I (122) esp_image: segment 0: paddr=00010020 vaddr=3f400020 size=26844h (157764) map

[13:31:00.393]收←◆I (188) esp_image: segment 1: paddr=0003686c vaddr=3ffbdb60 size=05834h ( 22580) load I (197) esp_image: segment 2: paddr=0003c0a8 vaddr=40080000 size=03f70h ( 16240) load I (204) esp_image: segment 3: paddr=00040020 vaddr=400d0020 size=947e4h (608228) map

[13:31:00.629]收←◆I (424) esp_image: segment 4: paddr=000d480c vaddr=40083f70 size=1b560h (111968) load

[13:31:00.693]收←◆I (486) boot: Loaded app [13:31:00.714]收←◆from partition at offset 0x10000 I (487) boot: Disabling RNG early entropy source... I (498) cpu_start: Multicore app I (499) cpu_start: Pro cpu up. I (499) cpu_start: Starting app cpu, entry point is 0x40081490 I (0) cpu_start: App cpu up. I (519) cpu_start: Pro cpu start user code I (519) cpu_start: cpu freq: 240000000 Hz I (519) cpu_start: Application information: I (523) cpu_start: Project name: network_adapter I (529) cpu_start: App version: 1 I (533) cpu_start: Compile time: Feb 27 2024 16:34:17 I (540) cpu_start: ELF file SHA256: 8920c917a8fe0cf2... I (545) cpu_start: ESP-IDF: v5.1.2-dirty I (551) cpu_start: Min [13:31:00.791]收←◆chip rev: v0.0 I (556) cpu_start: Max chip rev: v3.99  I (560) cpu_start: Chip rev: v1.1 I (565) heap_init: Initializing. RAM available for dynamic allocation: I (573) heap_init: At 3FFAFF10 len 000000F0 (0 KiB): DRAM I (578) heap_init: At 3FFB6388 len 00001C78 (7 KiB): DRAM I (584) heap_init: At 3FFB9A20 len 00004108 (16 KiB): DRAM I (591) heap_init: At 3FFCC358 len 00013CA8 (79 KiB): DRAM I (597) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM I (603) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM I (610) heap_init: At 4009F4D0 len 00000B30 (2 KiB): IRAM I (617) spi_flash: detected chip: generic I (620) spi_flash: flash io: dio I (625) coexist: coex firmware version: b6d5e8c I (630) app_start: Starting scheduler on CPU0 [0;32I (635) app_start: Starting scheduler on CPU1 mI (635) main_task: Started on CPU0 I (643) main_task: Calling app_main() I (645) NETWORK_ADAPTER:  I (653) NETWORK_ADAPTER: ESP-Hosted-FG Firmware version :: 0.0.5  I (661) NETWORK_ADAPTER: Transport used :: SDIO only  I (667) NETWORK_ADAPTER:  I (675) NETWORK_ADAPTER: Supported features are: I (679) NETWORK_ADAPTER: - WLAN over SDIO I (683) ESP_BT: - BT/BLE I (685) ESP_BT: - HCI Over SDIO I (689) ESP_BT: - BT/BLE dual mode I (693) NETWORK_ADAPTER: capabilities: 0x1d I (705) BTDM_INIT: BT controller compile version [ec4ac65] I (705) BTDM_INIT: Bluetooth MAC: 64:b7:08:3f:6f:2e I (709) phy_init: phy_version 4780,16b31a7,Sep 22 2023,20:42:16

[13:31:01.340]收←◆I (1033) NETWORK_ADAPTER: ESP Bluetooth MAC addr: 64:b7: 8:3f:6f:2e I (1033) SDIO_SLAVE: Using SDIO interface I (1035) SDIO_SLAVE: sdio_init: ESP32 SDIO timing: 0  I (1045) wifi:wifi driver task: 3ffda0f8, prio:23, stack:6656, core=1 I (1045) wifi:wifi firmware version: 91b9630 I (1047) wifi:wifi certification version: v7.0 I (1051) wifi:config NVS flash: disabled I (1053) wifi:config nano formating: disabled I (1057) wifi:Init data frame dynamic rx buffer num: 32 I (1061) wifi:Init static rx mgmt buffer num: 5 I (1063) wifi:Init management short buffer num: 32 I (1067) wifi:Init dynamic tx buffer num: 64 I (1071) wifi:Init static rx buffer size: 1600 I (1075) wifi:Init static rx buffer num: 16 I (1077) wifi:Init dynamic rx buffer num: 32 I (1081) wifi_init: rx ba win: 6 I (1083) wifi_init: tcpip mbox: 32 I (1087) wifi_init: udp mbox: 6 I (1089) wifi_init: tcp mbox: 6 I (1093) wifi_init: tcp tx win: 5744 I (1097) wifi_init: tcp rx win: 5744 I (1099) wifi_init: tcp mss: 1440 I (1103) wifi_init: WiFi IRAM OP enabled I (1107) wifi_init: WiFi RX IRAM OP enabled I (1113) wifi:mode : null

[mantriyogesh]

Hello @legendss13 ,

If you have already used SDIO with ESP-AT, I think you should be able to run ESP-Hosted as well.

Answers to your questions:

1. Pull-ups are needed (See exact requirement in porting_guide
2. Porting layer: following the answer:

Porting layer is available for ESP-Hosted.

Ready port layer:	Branch	port / doc	status	User level thoughts
master	doc	should work, but no lwip	STM we used did not have SDIO, but had SDMMC. So we needed small upper HAL layer rewrite to get STM SDIO working	HAL layer may or may not be needed if STM now supports SDIO out of the box
feature/esp_as_mcu_host	Port dir	SDIO with ESP works superb	ESP as SDIO master port available, new port layer for STM need to be done

The branch feature/esp_as_mcu_host has clear port layer is different from master, This branch works very reliably for SDIO with lwip udp tx/rx touching 50Mbps Over The Air.

SDIO master used: ESP32 / ESP32-S3 / ESP32-P4 (because as if now, these only ESP chipsets expose SDIO master peripheral) SDIO slave used: ESP32 or ESP32-C6 (because as if now, these are only chipsets that expose SDIO slave peripheral)

@claydonkey had done some SDIO porting for feature/esp_as_mcu_host on STM32 in #287 . But Cannot fetch current status of it.

Could you please let us know which STM32 you use, and it has SDMMC support or SDIO also is supported out of the box?

[legendss13]

I'm currently using STM32 F429IGT6. As you said, my hardware connection should be fine. I already have the full LWIP stack available in my program and I've verified it in ETH without any problems. My current thinking is: is it okay to directly connect the transceiver interface of SDIO with the transceiver task of LWIP?

/**

• @brief This function should do the actual transmission of the packet. The packet is
• contained in the pbuf that is passed to the function. This pbuf
• might be chained.
• @param netif the lwip network interface structure for this ethernetif
• @param p the MAC packet to send (e.g. IP packet including MAC addresses and type)
• @return ERR_OK if the packet could be sent
• an err_t value if the packet couldn't be sent
• @note Returning ERR_MEM here if a DMA queue of your MAC is full can lead to
• strange results. You might consider waiting for space in the DMA queue
• to become available since the stack doesn't retry to send a packet
• dropped because of memory failure (except for the TCP timers). */

static err_t low_level_output(struct netif netif, struct pbuf p) { uint32_t i = 0U; struct pbuf *q = NULL; err_t errval = ERR_OK; ETH_BufferTypeDef Txbuffer[ETH_TX_DESC_CNT] = {0};

memset(Txbuffer, 0 , ETH_TX_DESC_CNT*sizeof(ETH_BufferTypeDef));

for(q = p; q != NULL; q = q->next) { if(i >= ETH_TX_DESC_CNT) return ERR_IF;

Txbuffer[i].buffer = q->payload;
Txbuffer[i].len = q->len;

if(i>0)
{
  Txbuffer[i-1].next = &Txbuffer[i];
}

if(q->next == NULL)
{
  Txbuffer[i].next = NULL;
}

i++;

}

TxConfig.Length = p->tot_len; TxConfig.TxBuffer = Txbuffer; TxConfig.pData = p;

pbuf_ref(p);

**HAL_ETH_Transmit_IT(&heth, &TxConfig); while(osSemaphoreAcquire(TxPktSemaphore, TIME_WAITING_FOR_INPUT)!=osOK)

{ }

HAL_ETH_ReleaseTxPacket(&heth);**

return errval; }

/**

• @brief Should allocate a pbuf and transfer the bytes of the incoming
• packet from the interface into the pbuf.
• @param netif the lwip network interface structure for this ethernetif
• @return a pbuf filled with the received packet (including MAC header)

• NULL on memory error / static struct pbuf low_level_input(struct netif netif) { struct pbuf p = NULL;

  if(RxAllocStatus == RX_ALLOC_OK) { HAL_ETH_ReadData(&heth, (void )&p);** }

  return p; }

[legendss13]

Sorry, the code may not be clear：

[legendss13]

Sorry, the code may not be clear：

I refer to the practice here https://github.com/drorgl/stm32-lwip-esp-hosted/tree/master/stm32-lwip

[mantriyogesh]

1. https://github.com/espressif/esp-hosted/issues/347#issuecomment-1968403774 : It is little old code base
2. It is only SPI. For SDIO how do you want to proceed?
3. As I check in https://www.mouser.sg/datasheet/2/389/stm32f427vg-1760963.pdf, your device support out of the box SDIO, so I suppose the HAL also would support.

Sorry, the code may not be clear：

right, this would be a hook function (may be from lwip or any networking interface). You can hook it to send_to slave(...) or esp_hosted_tx(...)

Basically correct path, for from scratch porting. but the new branch, already takes care of this.

For example, in case of new branch, along with esp_wifi_remote_21feb23.tar.gz

if you browse, you would see that the Wi-Fi netif ends(hooks) tx in _transportdrv.c : transport_drv_sta_tx() -> _sdiodrv.c : esp_hosted_tx() which sends the buffer in queue, _to_slavequeue which on dequeue, sent through the port function, g_h.funcs->_h_sdio_write_block() . This ends to the (ESP's) ported function _sdiowrapper.c : port function, hosted_sdio_write_block()

[legendss13]

We may not be in a time zone, sorry we can't reply in time. The F429 HAL I'm using at the moment doesn't see SDIO drivers only SD and MMC, so I did a sdio protocol code port based on the STM32 journey in esp-sdio. Yes I saw the new driver, he looks much clearer and independent, I will try to port it with it. I hope to have a full LWIP+hosted solution to be shown in stm32 in the future. It can be any chip. It's going to be great to help rookies like me save time

[legendss13]

Now I'm making new progress, but I don't know what that means. Because the STM32 program still can't be run. Can you give me a look at where I'm going to troubleshoot next? Here are some logs from ESP32：

I (1063) wifi:Init dynamic rx buffer num: 32 [0; 32mI (1067) wifi_init: rx ba win: 6 [0; 32mI (1069) wifi_init: tcpip mbox: 32 [0; 32mI (1073) wifi_init: udp mbox: 6 [0; 32mI (1075) wifi_init: tcp mbox: 6 [0; 32mI (1079) wifi_init: tcp tx win: 5744 [0; 32mI (1081) wifi_init: tcp rx win: 5744 [0; 32mI (1085) wifi_init: tcp mss: 1440 [0; 32mI (1089) wifi_init: WiFi IRAM OP enabled [0; 32mI (1093) wifi_init: WiFi RX IRAM OP enabled I (1099) wifi:mode : null

[17:13:05.019]← Close◆[0; 32mI (4985) NETWORK_ADAPTER: Start Data Path

[17:13:05.168]← closed◆[0; 32mI (5105) NETWORK_ADAPTER: Initial set up done [0; 32mI (5105) slave_ctrl: event ESPInit [0; 32mI (5105) main_task: Returned from app_main()

logs from stm32： V sdio_transport: get_intr D sdio_transport: clear_intr: 00080000 V STM32_sdio: Send size:4

V STM32_sdio: CMD53 response

V sdio_transport: get_intr D sdio_transport: clear_intr: 00CC4000 V STM32_sdio: Send size:4

V STM32_sdio: CMD53 response

D sdio_transport: get_packet: slave len=23, max read size=1536 V sdio_transport: get_intr D sdio_transport: clear_intr: 004C7000 V STM32_sdio: Send size:4

V STM32_sdio: CMD53 response

V sdio_transport: get_intr D sdio_transport: clear_intr: 008C0000 V STM32_sdio: Send size:4

V STM32_sdio: CMD53 response

D sdio_transport: get_packet: slave len=34, max read size=1536 V sdio_transport: get_intr D sdio_transport: clear_intr: 004C7000 V STM32_sdio: Send size:4

V STM32_sdio: CMD53 response

V sdio_transport: get_intr

[17:15:14.890]收←◆V sdio_transport: get_intr

[17:15:14.922]收←◆V sdio_transport: get_intr

[17:15:14.951]收←◆V sdio_transport: get_intr

[17:15:14.984]收←◆V sdio_transport: get_intr

[17:15:15.014]收←◆V sdio_transport: get_intr

STM32 keeps printing repeatedly： V sdio_transport: get_intr

[mantriyogesh]

Actually, the driver in the master is polling based.

To make it interrupt based, You might want to block on getting real interrupt on SDIO D1 line.

stm_ret_t sdio_host_get_intr(uint32_t* intr_st)
{
    stm_ret_t ret = STM_OK;

    if (intr_st == NULL) {
        return STM_FAIL_INVALID_ARG;
    }

 /****
  * //Hook your ST's SDIO blocking interrupt function here
  * 
  * ret = st_sdio_interrupt_recv_blocking();
  * if (ret) {
  *   return STM_FAIL;
  * }
  * 
  * // provide definition of st_sdio_interrupt_recv_blocking() referring to your SDIO HAL
  *****/

    if (intr_st != NULL) {
        ret = sdio_driver_read_bytes(SDIO_FUNC_1,
                SDIO_REG(ESP_SLAVE_INT_ST_REG), (uint8_t*)intr_st, 4, 0);
        if (ret) {
            return ret;
        }
    }

    return STM_OK;
}

For example, in case of ESP32, in new branch, feature/esp_as_mcu_host this is implemented as:

Call tree: SDIO driver checks interrupt: https://github.com/espressif/esp-hosted/blob/504f4f203c27d5a9e5e3bb1b34f7101e43cd8f59/host/drivers/transport/sdio/sdio_drv.c#L636

Hook: https://github.com/espressif/esp-hosted/blob/504f4f203c27d5a9e5e3bb1b34f7101e43cd8f59/host/port/os_wrapper.c#L801

Port for ESP32 (Hook implementation): https://github.com/espressif/esp-hosted/blob/504f4f203c27d5a9e5e3bb1b34f7101e43cd8f59/host/port/sdio_wrapper.c#L409-L414

This new branch focuses on the port layer and easy portability for any new MCU. JFYI, Porting for one of STM32 SDIO (NUCLEO-H743ZI2) on this branch is one of the tasks we are going to take up in near future.

[legendss13]

Thank you for your patience, I've changed to interrupt to read the data. But I found a new problem, and after I initialized it, I received the following data:

0x5 00 0xb 00 0xc 00 00 00 00 00 00

0x3 00 0x16 00 0xc 00 00 00 00 00 00 00 0x1 0x8 00 0x63 0x74 0x72 0x6c 0x45 0x76 0x6e

I don't know what this means, the code says it should be dirty data?Here's the original print:

I checked the code and the stm32 side didn't send data to esp-sdio before that。 Here's my initialization process： The program is stuck at the mark。（Some related functions：）

[legendss13]

The error here looks like something is not initialized mainly because it is not called here, where is it called when it is initialized?

[legendss13]

Eventually leads to an error here：

[mantriyogesh]

Actually, many of such semphore issues are fixed in 'feature/esp_as_mcu_host' branch.

Possibly the issue you face is because the semaphores are binary but should be counting. But clearly, porting 'feature/esp_as_mcu_host' branch would have helped you much.

I am actually porting that branch for SPI, and once I am finished, I will be doing it for SDIO. but it might take 2 weeks or so..

[legendss13]

Thanks for your reply, I also looked at "feature/esp_as_mcu_host" before this, and it seems that the overall process is not much worse, and I am still in the verification testing stage, so I haven't ported that branch code. I'll try to fix this semaphore, it looks like it's being called when the semaphore isn't initialized.

[legendss13]

I have made a new progress, is this already connected to WiFi?Why does the AP prompt that there is no device connected? And using DHCP does not obtain an IP address。

[mantriyogesh]

It is connected to Wi-Fi (AP).

The master branch only showcases 'ARP'. It doesn't run full lwip. So you may not be directly expect dhcp running.

You can try to run 'arping' as mentioned in the ARP documentation, to verify if it is communicating with Wi-Fi.

'arping' is not layer 3. it just showcase that the packets run through the Wi-Fi. For lwip, you would still need to integrate lwip (feature/esp_as_mcu_host has it all integrated for esp32)

[legendss13]

You're right, it's true that there is a problem with my lwip configuration, I have successfully obtained the IP after modifying it, and I will do the next TCP connection adaptation. Thank you for your patience and look forward to Hoseted+LWIP

[legendss13]

Now I can send data to the MQTT server as normal. But three problems were encountered:

1. I'll come back when I'm connected to WiFi [15:02:40.877] Received← ◆ 01 08 00 63 74 72 6c 52 65 73 70 02 08 00 08 02 10 cc 01 e2 0c 00 NULL MAC returned Failed to get wifi mac”。 The frequency of this problem is still quite high, and I don't know the specific reason (is it because the frequency of reconnecting the AP is fast?).
2. When I send data, the data below 1k can be sent normally, and if it is greater than this value, it will not be returned, I can make sure that my LWIP and mqtt work normally. Limited to ESP32?
3. Occasionally, CMD53 time out will fail to read data.