esp-hosted/features error in esp_wifi_init(&cfg) (EHM-10)

[claydonkey]

I'll keep it short. I'm running the station_example_main.c entry point. Other than adding esp_hosted_init(NULL); before app_main(); I haven't changed anything from the current branch.

HOST

I ESP-Hosted starting. Hosted_Tasks: prio:2, stack: 5120 RPC_task_stack: 4096

I ********************************************************
I ********************************************************
I ********             ESP-Hosted                 ********
I ********************************************************
I ********************************************************
I SDIO CLK Freq: 280Mhz ClockDiv: 14
I Transport - SDIO
SDIO master, CLK Freq: 10Mhz
RCA: 1

bus_width 64. Clock Div 350
bus_width 66. Clock Div 14
D >0x2400976c   01 03 d9 01 ff 20 04 66  66 22 22 21 02 0c 00 22  |..... .ff""!..."|
D  0x2400977c   04 00 00 02 32 1a 05 01  01 00 02 07 1b 08 c1 41  |....2..........A|
D  0x2400978c   30 30 ff ff ff ff ff                              |00.....|
TUPLE: DEVICE, size: 3: D9 01 FF
TUPLE: MANFID, size: 4
  MANF: 6666, CARD: 2222
TUPLE: FUNCID, size: 2: 0C 00
TUPLE: FUNCE, size: 4: 00 00 02 32
TUPLE: CONFIG, size: 5: 01 01 00 02 07
TUPLE: CFTABLE_ENTRY, size: 8
  INDX: C1, Intface: 1, Default: 1, Conf-Entry-Num: 1
  IF: 41
  FS: 30, misc: 0, mem_space: 1, irq: 1, io_space: 0, timing: 0, power: 0
  IR: 30, mask: 1,   IRQ: FF FF
  LEN: FFFF
TUPLE: END
D IOE: 0x02
D IOR: 0x02
D IOE: 0x02
D IOE: 0x02
D IOR: 0x02
D IE: 0x00
D IE: 0x03
D BUS_WIDTH: 0x42
I Function 0 Blocksize: 512
I Function 1 Blocksize: 512
D rpc_init
D rpc_slaveif_init
I ESP_WIFI_MODE_STA
D LwIP stack has been initialized
D esp-netif has been successfully initialized
D created task for loop 0x240221f8
D created event loop 0x240221f8
D esp_netif_add_to_list 0x24029ec0
D esp_netif_add_to_list netif added successfully (total netifs: 1)
D check: remote, if=0 fn=0x90007971

D call api in lwip: ret=0x0, give sem
D Register sync sem 0x2402a1f0 for resp[0x216]

I <-- RPC_Req  [0x116]
D Sent RPC_Req[0x116]

D >0x2402a364   22 09 12 01 00 11 01 1d  13 01 00                 |"..........|
I Received INIT event from ESP32 peripheral
D Init event length: 9
I EVENT: 12
I EVENT: 11
I capabilities: 0x1d
I Features supported are:
I        * WLAN
I        * BT/BLE
I          - HCI over SDIO
I          - BT/BLE dual mode
I EVENT: 13
D priv test raw tp

I ESP board type is : 0

I Received INIT event
I Base transport is set-up

D >0x2402a364   01 06 00 52 50 43 45 76  74 02 08 00 08 03 10 81  |...RPCEvt.......|
D  0x2402a374   06 8a 30 00                                       |..0.|
D Received Event [0x301]

D EVENT: ESP INIT

I Received Slave ESP Init
D >0x2402a974   01 06 00 52 50 43 52 73  70 02 0b 00 08 02 10 96  |...RPCRsp.......|
D  0x2402a984   04 b2 21 03 08 82 02                              |..!....|
D Received Resp [0x216]

I  --> RPC_Resp [0x216]
E Failure resp/event: possibly precondition not met
E Failed Control Response

ESP_ERROR_CHECK failed: esp_err_t 0xffffffff (ESP_FAIL) at 0x90024319
file: "../Core/port/examples/wifi/station/main/station_example_main.c" line 113
func: wifi_init_sta
expression: esp_wifi_init(&cfg)

SLAVE

I (446) NETWORK_ADAPTER: *********************************************************************
I (454) NETWORK_ADAPTER:                 ESP-Hosted-FG Slave Firmware version :: 0.0.5
I (462) NETWORK_ADAPTER:                 Transport used :: SDIO only
I (468) NETWORK_ADAPTER: *********************************************************************
I (476) gpio: GPIO[0]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
I (484) gpio: GPIO[0]| InputEn: 1| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
I (492) NETWORK_ADAPTER: Supported features are:
I (496) NETWORK_ADAPTER: - WLAN over SDIO
I (498) ESP_BT: - BT/BLE
I (502) ESP_BT:    - HCI Over SDIO
I (504) ESP_BT:    - BT/BLE dual mode
I (508) NETWORK_ADAPTER: capabilities: 0x1d
I (532) BTDM_INIT: BT controller compile version [153f120]
I (532) BTDM_INIT: Bluetooth MAC: 48:e7:29:99:29:9a
I (534) phy_init: phy_version 4771,450c73b,Aug 16 2023,11:03:10
I (842) NETWORK_ADAPTER: ESP Bluetooth MAC addr: 48:e7:29:99:29:9a
I (844) SDIO_SLAVE: Using SDIO interface
I (844) SDIO_SLAVE: sdio_init: ESP32 SDIO timing: 0

I (1496) NETWORK_ADAPTER: Start Data Path
I (1540) NETWORK_ADAPTER: Initial set up done
I (1540) slave_ctrl: event ESPInit
I (1540) main_task: Returned from app_main()
I (1606) slave_ctrl: Resp_MSGId for req[0x116] is [0x216]
I (1606) slave_ctrl: Received Req [0x116]
E (1608) wifi:dynamic tx buf number 0 is out of range
I (1610) wifi_init: rx ba win: 6
I (1614) wifi_init: tcpip mbox: 32
I (1616) wifi_init: udp mbox: 6
I (1620) wifi_init: tcp mbox: 6
I (1622) wifi_init: tcp tx win: 5744
I (1626) wifi_init: tcp rx win: 5744
I (1630) wifi_init: tcp mss: 1440
I (1632) wifi_init: WiFi IRAM OP enabled
I (1636) wifi_init: WiFi RX IRAM OP enabled
E (1640) slave_ctrl: req_wifi_init:1016 failed [esp_wifi_init(&cfg)] = [258]

[SohKamYung-Espressif]

In your log:

D call api in lwip: ret=0x0, give sem
D Register sync sem 0x2402a1f0 for resp[0x216]

I <-- RPC_Req  [0x116]
D Sent RPC_Req[0x116]

D >0x2402a364   22 09 12 01 00 11 01 1d  13 01 00                 |"..........|
I Received INIT event from ESP32 peripheral
D Init event length: 9
I EVENT: 12
I EVENT: 11
I capabilities: 0x1d
D call api in lwip: ret=0x0, give sem
D Register sync sem 0x2402a1f0 for resp[0x216]

I <-- RPC_Req  [0x116]
D Sent RPC_Req[0x116]

D >0x2402a364   22 09 12 01 00 11 01 1d  13 01 00                 |"..........|
I Received INIT event from ESP32 peripheral
D Init event length: 9
I EVENT: 12
I EVENT: 11
I capabilities: 0x1d
I Features supported are:
I        * WLAN
I        * BT/BLE
I          - HCI over SDIO
I          - BT/BLE dual modeI Features supported are:
I        * WLAN
I        * BT/BLE
I          - HCI over SDIO
I          - BT/BLE dual mode

Sequencing does not look correct. Host sends esp_wifi_init() (RpcID 0x116) before the Slave init event was received by the host.

For reference, on my system, the sequence of events on the host is:

I (1837) sdio_wrapper: Function 0 Blocksize: 512
I (1837) sdio_wrapper: Function 1 Blocksize: 512
I (1847) H_SDIO_DRV: generate slave intr
I (1847) H_SDIO_DRV: enter sdio_generate_slave_intr
I (1947) transport: Received INIT event from ESP32 peripheral
I (1947) transport: EVENT: 12
I (1947) transport: EVENT: 11
I (1947) transport: capabilities: 0xd
I (1957) transport: Features supported are:
I (1957) transport:      * WLAN
I (1967) transport:      * BT/BLE
I (1967) transport:        - HCI over SDIO
I (1977) transport:        - BLE only
I (1977) transport: EVENT: 13
I (1977) transport: ESP board type is : 13 

I (1987) H_SDIO_DRV: Received INIT event
I (1987) transport: Base transport is set-up

I (1997) rpc_wrap: Received Slave ESP Init
I (2727) rpc_core: <-- RPC_Req  [0x116]
I (2837) rpc_rsp:  --> RPC_Resp [0x216]
I (2837) rpc_core: <-- RPC_Req  [0x104]
I (2847) rpc_rsp:  --> RPC_Resp [0x204]
I (2847) rpc_core: <-- RPC_Req  [0x11c]
I (2887) rpc_rsp:  --> RPC_Resp [0x21c]
I (2887) rpc_core: <-- RPC_Req  [0x118]
I (2957) rpc_rsp:  --> RPC_Resp [0x218]
I (2957) wifi station: wifi_init_sta finished.
I (2957) rpc_evt: Event [0x2] received
I (2957) rpc_evt: EVT rcvd: Wi-Fi Start
I (2957) rpc_core: <-- RPC_Req  [0x101]
I (2977) rpc_rsp:  --> RPC_Resp [0x201]
I (2977) wifi station: event: start 2
I (2977) H_API: esp_hosted_wifi_connect
I (2977) rpc_core: <-- RPC_Req  [0x11a]
I (2997) rpc_rsp:  --> RPC_Resp [0x21a]
I (4987) esp_netif_handlers: sta ip: 10.10.2.205, mask: 255.255.255.0, gw: 10.10.2.1
I (4987) wifi station: got ip:10.10.2.205

In station_example_main.c, there is also this piece of code:

   wifi_init_config_t cfg = WIFI_INIT_CONFIG_DEFAULT();
    ESP_ERROR_CHECK(esp_wifi_init(&cfg));

Your implementation of the WIFI_INIT_CONFIG_DEFAULT() macro should match what is in version of ESP-IDF used to build the code for the slave device, otherwise the parameters sent to initialize the wifi could be wrong.

[claydonkey]

Thanks @SohKamYung-Espressif Problem solved.

1. I hadn't migrated the old port code correctly. In fact I ditched my old wifi.c entirely and the WEAK function seem to take care of everything

esp_err_t esp_wifi_init(const wifi_init_config_t *config)
{
    ESP_LOGV(TAG, "Trigger Wifi init");
    return rpc_wifi_init(config);
}

The Overloaded function...

WEAK esp_err_t esp_wifi_init(const wifi_init_config_t *config)
{
    return remote_esp_wifi_init(config);
}
esp_err_t esp_hosted_wifi_init(const wifi_init_config_t *arg)
{
    ESP_ERROR_CHECK(transport_drv_reconfigure()); // this was not called in my old overriden esp_hosted_wifi_init
    return rpc_wifi_init(arg);
}

2. + more importantly the clue to the failure was indicated here:

E (1608) wifi:dynamic tx buf number 0 is out of range

I had to define the following

#define CONFIG_ESP_WIFI_STATIC_RX_BUFFER_NUM 12
#define CONFIG_ESP_WIFI_DYNAMIC_RX_BUFFER_NUM 48
#define CONFIG_ESP_WIFI_DYNAMIC_TX_BUFFER_NUM 48
#define CONFIG_ESP_WIFI_AMPDU_TX_ENABLED 1
#define CONFIG_ESP_WIFI_TX_BA_WIN 12
#define CONFIG_ESP_WIFI_AMPDU_RX_ENABLED 1
#define CONFIG_ESP_WIFI_RX_BA_WIN 12

#define CONFIG_LWIP_TCP_SND_BUF_DEFAULT 11488
#define CONFIG_LWIP_TCP_WND_DEFAULT 11488
#define CONFIG_LWIP_TCP_RECVMBOX_SIZE 12
#define CONFIG_LWIP_UDP_RECVMBOX_SIZE 12
#define CONFIG_LWIP_TCPIP_RECVMBOX_SIZE 48
#define CONFIG_LWIP_ETHARP_TRUST_IP_MAC 0 

The result:

[DFU_H7B0]: ORIGIN ADDRESS               24100000.
[DFU_H7B0]: XIP code found - executing JumpAddress 90000F7D.
I H_API ESP-Hosted starting. Hosted_Tasks: prio:2, stack: 5120 RPC_task_stack: 4096

I os_wrapper ********************************************************
I os_wrapper ********************************************************
I os_wrapper ********             ESP-Hosted                 ********
I os_wrapper ********************************************************
I os_wrapper ********************************************************
I os_wrapper SDIO CLK Freq: 280Mhz ClockDiv: 14
I os_wrapper Transport - SDIO
SDIO master, CLK Freq: 10Mhz
I station_ex ESP_WIFI_MODE_STA
I esp_remote_wifi_init remote_esp_wifi_init_slave
I transport Add ESP-Hosted channel IF[0]: S[0] Tx[0x90022939] Rx[0x90019205]
I transport Add ESP-Hosted channel IF[1]: S[0] Tx[0x900229e9] Rx[0x90019205]
I transport Attempt connection with slave: retry[0]
I transport Reset slave using GPIO[16]
I H_SDIO_DRV transport has been reset
I sdio_wrapper RCA: 1

I sdio_wrapper bus_width 64. Clock Div 14

I sdio_wrapper bus_width 66. Clock Div 14

I sdio_wrapper Function 0 Blocksize: 512
I sdio_wrapper Function 1 Blocksize: 512
I H_SDIO_DRV generate slave intr
I transport Received INIT event from ESP32 peripheral
I transport EVENT: 12
I transport EVENT: 11
I transport capabilities: 0x1d
I transport Features supported are:
I transport      * WLAN
I transport      * BT/BLE
I transport        - HCI over SDIO
I transport        - BT/BLE dual mode
I transport EVENT: 13
I transport ESP board type is : 0

I H_SDIO_DRV Received INIT event
I transport Base transport is set-up

I rpc_wrap Received Slave ESP Init
I rpc_core <-- RPC_Req  [0x116]
I rpc_rsp  --> RPC_Resp [0x216]
I rpc_core <-- RPC_Req  [0x104]
I rpc_rsp  --> RPC_Resp [0x204]
I rpc_core <-- RPC_Req  [0x11c]
I rpc_rsp  --> RPC_Resp [0x21c]
I rpc_core <-- RPC_Req  [0x118]
I rpc_rsp  --> RPC_Resp [0x218]
I station_ex wifi_init_sta finished.
I rpc_evt Event [0x2] received
I rpc_evt EVT rcvd: Wi-Fi Start
I rpc_core <-- RPC_Req  [0x101]
I rpc_rsp  --> RPC_Resp [0x201]
I esp_netif_handlers esp_netif_action_start with netif0x24029ec0 from event_id=2
I H_API esp_hosted_wifi_connect
I rpc_core <-- RPC_Req  [0x11a]
I rpc_rsp  --> RPC_Resp [0x21a]
I H_API esp_hosted_wifi_connect
I rpc_core <-- RPC_Req  [0x11a]
I rpc_rsp  --> RPC_Resp [0x21a]
I station_ex retry to connect to the AP
I station_ex connect to the AP fail
I H_API esp_hosted_wifi_connect
I rpc_core <-- RPC_Req  [0x11a]
I rpc_rsp  --> RPC_Resp [0x21a]
I station_ex retry to connect to the AP
I station_ex connect to the AP fail
I esp_netif_handlers esp_netif_action_connected with netif0x24029ec0 from event_id=4
I esp_netif_handlers esp_netif action got_ip with netif0x24029ec0 from event_id=0
I esp_netif_handlers sta ip: 192.168.1.220, mask: 255.255.255.0, gw: 192.168.1.254
I station_ex got ip:192.168.1.220
I station_ex connected to ap SSID:EE-Hub-g4rP password:************

@SohKamYung-Espressif + @mantriyogesh SUCCESS. Thanks + have a great weekend

[SohKamYung-Espressif]

@claydonkey That is good.

Just to check. Does this also resolve your other open issues like https://github.com/espressif/esp-hosted/issues/283 , https://github.com/espressif/esp-hosted/issues/270 ?

[claydonkey]

Good Day @SohKamYung-Espressif

The problem is still there for espressif/esp-hosted#283 but I am more aware of what's going on..

hosted_sdio_wait_slave_intr(uint32_t ticks_to_wait) and the STM32

A problem with the STM32

The stm32H7 is not raising an interrupt (SDIOIT Flag) when the interrupt pin goes low.

So until I work out the problem I am trying:

1. SDIOIT Interrupt
2. Polling the pin
3. Blocking

#define INT_BLOCKING 1
#define INT_SDIOIT 2
#define INT_POLLING 3
#define INTR_TYPE INT_POLLING

int hosted_sdio_wait_slave_intr(uint32_t ticks_to_wait) {

    SDIO_FAIL_IF_NULL(hsd1->Instance);

#if INTR_TYPE == INT_BLOCKING || INTR_TYPE ==  INT_SDIOIT
    uint32_t start = HAL_GetTick();
//3. Blocking
    while (g_h.funcs->_h_read_gpio(GPIOC, GPIO_PIN_9)) {
#if INTR_TYPE ==  INT_SDIOIT
//1. SDIOIT interrupt
        if(IntrStatus.status != data_empty) //1. SDIOIT interrupt
        {
            IntrStatus.status = data_empty;
            break;
        }
#endif
        if ((HAL_GetTick() - start) > ticks_to_wait)
        {
            ESP_LOGE(TAG,"sdio_wait_slave_intr timeout");
            break;
        }
    };
    return ESP_OK;
#elif INTR_TYPE == INT_POLLING
//2. Polling
     return (g_h.funcs->_h_read_gpio(GPIOC, GPIO_PIN_9));//3. polling
#endif
}

1. Doesn't execute at all (not esp-hosted - issue with STM32)
2. E wait_slave_intr error: 1 in sdio_drv.c
3. E sdio_wait_slave_intr timeout Times out in code above

so I just have to allow the host to function by altering:

res = g_h.funcs->_h_sdio_card_init(sdio_handle);

to

res = ESP_OK;

Now sdio_get_intr(&interrupts) executes every sdio_read_task cycle and I think this is making the slave bomb.

In Iperf I am getting only 10mbps up and downstream and I think this is also the reason why the throughput is as low as it is.

[mantriyogesh]

Interrupts are only sent outside the data transfer periods

If so, in case of polling, worth to check for any incoming data, for second time, post valid transfer.

Also, please cross check granularity of HAL_GetTick(), for your reference. You can also use some precision timer if need be.

Normally you can configure the sending of an SDIO interrupt in the SDIO slave even if a transfer is ongoing

Well, I'm not sure right now, Might have to check the ESP-IDF SDIO code for this.

Can you reduce the clock and get the SDIO logic analyzer dump? This will actually give good understanding of bus operations.

[claydonkey]

@mantriyogesh

Can you reduce the clock and get the SDIO logic analyzer dump? This will actually give good understanding of bus operations.

I'll have to dust off the Saleae clone. Not sure what speed it supports - says 25Mhz.

Interrupts are only sent outside the data transfer periods

Yes and I think there's the rub.

I don't think the interrupt is firing at all because the task loops are so tight. Perhaps I need to introduce some delay between transmissions.

Also I have been looking at ##### Responses management functions ##### I had been employing R1 for both reads and writes. Changing to an R3 (OCR) response seems to have picked up the pace a bit, as it's now there's no waiting for SDMMC_FLAG_BUSYD0END which I believe was an error on my part.

If so, in case of polling, worth to check for any incoming data, for second time, post valid transfer.

I have tried using a semaphore sdio_trans_ready_sem in sdio_ll.c to acheive this effect:

int hosted_sdio_wait_slave_intr(uint32_t timeout_ticks) {

    SDIO_FAIL_IF_NULL(hsd1->Instance);
    __HAL_SD_DISABLE_IT(hsd1, SDMMC_IT_SDIOIT);

    if (!g_h.funcs->_h_read_gpio(GPIOC, GPIO_PIN_9)){
        return ESP_OK;
    }
    g_h.funcs->_h_get_semaphore(sdio_trans_ready_sem, 0);
    __HAL_SD_ENABLE_IT(hsd1, SDMMC_IT_SDIOIT);

    if (g_h.funcs->_h_get_semaphore(sdio_trans_ready_sem, timeout_ticks) == pdTRUE) {
        g_h.funcs->_h_post_semaphore(sdio_trans_ready_sem);
        return ESP_OK;
    } 
    else{
        return ESP_ERR_TIMEOUT;
    }

    return ESP_OK;
}

void SDMMC1_IRQHandler(void) {

    SD_HandleTypeDef *card = hsd1;
    uint32_t context = card->Context;

    if (__HAL_SD_GET_FLAG(card, SDMMC_FLAG_SDIOIT)) {
        ESP_LOGI(TAG, "SDMMC_IT_SDIOIT\n\r");
        __HAL_SD_DISABLE_IT(card, SDMMC_IT_SDIOIT);
        g_h.funcs->_h_post_semaphore_from_isr(sdio_trans_ready_sem);
    }

[mantriyogesh]

Little confusing in the start, I am still trying to get all branching possible and interrupt behaviours in all returns (by mistake, the interrupt should not be disabled or cleared)

Just different set of basic questions popped in my mind, which I think you would already might be coverering: (a) SDIO is expected to be using pull-ups on the pins CMD, D0-D3. We used external 51kOhm in our PCB. (b) The size of wires will limit your all speed and signal integrity. Higher frequencies will be very bad for jumper wires. (c) for higher frequencies, you can connect as many ground available for signal stability, but still pcb would be must.

[mantriyogesh]

Also, Does the SDMMC IRQ handler work for SDIO? If yes, why to handle the interrupt manually?

I mean, either your code handles the interrupt fully, or let the HAL handle (unless issues/Limitations in the HAL).

Also the time outs are in the ticks, but tick need to be not very small (heavy CPU loading) nor too big (slow communication or timeouts)

[claydonkey]

@mantriyogesh

Good questions!

I got your email and I am trying to compile a legible driver for you to look at...

(a) Yes all pull ups are as SDMMC requires (I'm using the pullups that already exist on the pcb for the sdmmc card slot. (b) Tiny wires max of 3cms. Mainly 1-2cms (c) I'm sure the integrity of the traces/wires are satisfactory

Also, Does the SDMMC IRQ handler work for SDIO? If yes, why to handle the interrupt manually?

When the SDIOIT starts working, I will have the sdio_read_task executed from the isr. To begin with I am adhering as much as I can to the original(features) code: setting a flag from the isrIntrStatus.status = data_full; which is polled from hosted_sdio_wait_slave_int. I just need to get a result with the SDIOT flag first.

It seems prevention of SDIOIT is due to either: a. The data routines are running too tightly together. (like you suggest a logic analyser would prove this) b. The _IT data commands clear the flag somewhere in the HAL but more likely in the peripheral hardware.

As a test I disabled the data read/writes after the smd53 commands: and I see the SDIOT flag interrupt being set from the D1 pin reset - I remember in the original esp-hosted the SDIOT flag was set. In that version because I translated the stm32F series routines which were all blocking call (no _IT functions) the routines introduced more delay implicitly (+ in addition I think you introduced some delays in the master branch version to allow for this very issue) + obviously the new version is faster by design, so it makes sense that something would have to give.

I have got some nicer results of 14mbps UDP slave>host. So things are improving.

Enter the World of the Tweak Freak

Using iPerf, the tcpip task asked for a lot of stack.

Having got the:

E tx fail: NULL buff, invalid len (90) or len > max len (1512))

copy_buff = mempool_alloc(((struct mempool*)chan_arr[ESP_STA_IF]->memp), MAX_SDIO_BUFFER_SIZE, true);

cannot alloc with 256k as configTOTAL_HEAP_SIZE; I've increased the stack to 512k

configTOTAL_HEAP_SIZE  == 512k 
uint8_t ucHeap[ configTOTAL_HEAP_SIZE ] __attribute__((section (".DATA_SDMMCRAM")));

Then I got

I Retry get write buffers 2

So I Increased buffers to

#define ESP_RX_BYTE_MAX                0x100000
#define ESP_RX_BUFFER_SIZE             0x10000
#define ESP_TX_BUFFER_MASK             0xFFF
#define ESP_TX_BUFFER_MAX              0x10000

Esp-hosted is beginning to take up a lot of memory.... How should one go about to streamlining the memory? Doesn't this all seem a little too much?

[mantriyogesh]

What is the current frequency of the sdio clk? I think the logic analyzer will also tell of bus is being saturated or underutilized..

You can also try to disable mempool and rely on the normal mallocs. Mempool at host is just cache of the alloc pointers, https://github.com/espressif/esp-hosted/blob/feature/esp_as_mcu_host/host/drivers/mempool/mempool.c#L97-L100

Mempool might be allocating higher block sizes than it needs. This came from spi background, where the block size is fixed to 1600. Sdio case it still depends upon use, it could be exact size / aligned with DMA/ Aligned with block size that is 512. Depending upon how much are sending. (Both, start address and allocation size)

You can also comment mempool by undefining CONFIG_ESP_CACHE_MALLOC in sdkconfig.h or your config, where it should be. But despite commenting, if you see this issue, we would have to optimize above paragraph.

There is also probability of using lwip mempool instead of our own, which can easily be hooked, but need to be careful for modularity while using it.

Another question, what the task priority of the tasks? Is one task not getting fair share in Rx and TX due to Rx task being a polling?

[claydonkey]

@mantriyogesh @SohKamYung-Espressif

So I dusted down the analyzer and booted up the rather nice new Saleae Logic 2. The Host SDIO is running at a pedestrian 1Mhz

I can post any details you wish but here's the basics so far:

Exhibit a.

Continuous polling of interrupt command. You can see D1 is going low though sporadically

This is the general anatomy of (I assume data transmission) Should the lock/unlock command (CMD42) be there ?

Exhibit b.

Checking for interrupt on pin D1. No SDIOIT Flag is raised so ... Stops processing in initialization.

Exhibit c.

General activity during iPerf UDP Host as Server. Where is the interrupt ?? Hidden in that mess?

[mantriyogesh]

Possibly extra/different line with the interrupt might have been raised from esp32 code. But might need to dig where this would actually be in sdio hal.

[claydonkey]

@mantriyogesh
yes exactly what I'm looking at Looks suspect.... Look where the pin interrupt is covered over by that command... I wrote all the 53 CMDS so I can't imagine where the CMD42 is coming from. Digging deeper....

I know next to nothing a bout the SDIO Protocol. Could that CMD40 be send from the slave? If so the pin triggering happens very soon after. This looks like where the problem may lie.

[claydonkey]

I'm just gonna ramble here:

a. Pin is set low over data path b. Pin sometimes does not go low at all (could that be a voltage problem?) This logic probe reports the same as the host. Although it is a cheap clone it has seen me in good stead over the years c .What is CMD42 (and CMD40) Lock/Unlock - a security command for SDMMC?. There is no explicit reference in any of the STM HAL library - and no mention in the peripheral documents. Could it be that the analyser is conflating the data transaction initialization/termination registers?

[claydonkey]

@mantriyogesh @SohKamYung-Espressif So as you can see clearly in this picture the interrupt moves quite a bit:

I have resorted to either relying on a spontaneous read or waiting for a bit until the interrupt is generated. Your suggestion

Also, please cross check granularity of HAL_GetTick(), for your reference. You can also use some precision timer if need be.

Is good advice and I have implemented a us timer but anything short of a tick seems to be too quick.

sdio_read_task:

for (;;) {
   sdio_itr_delay_timer = xTaskGetTickCount();

   for (;;) {
      if (g_h.funcs->_h_sdio_wait_slave_intr(1)) {
         continue;
      }
}

int sdio_wait_slave_intr(const uint32_t ticks_to_wait) {

    if (!g_h.funcs->_h_read_gpio(SDMMC1_D1_GPIO_Port, SDMMC1_D1_Pin))
        return 0;

    vTaskDelayUntil(&sdio_itr_delay_timer, ticks_to_wait);

    return g_h.funcs->_h_read_gpio(SDMMC1_D1_GPIO_Port, SDMMC1_D1_Pin);
}

vTaskDelayUntil is useful as it doesn't block unlike vTaskDelay.

Also I assume the CMD42 and such are the data sent along with cmds

Unfortunately I am getting 15Mbps max currrently (iPerf Server UDP) (increasing from 20Mhz makes no diff). I imagine some tweaking to get more granularity in the timer will help.

[SohKamYung-Espressif]

What is CMD42 (and CMD40) Lock/Unlock - a security command for SDMMC

I think I can clear this part up. It's actually the R5 response from the slave device, not CMD40. See the diagram below for read (similar for write) which I took from the SD Part 1: Physical Layer Simplified Specification, downloaded from https://www.sdcard.org/downloads/pls/

[SohKamYung-Espressif]

Exhibit c.

General activity during iPerf UDP Host as Server. Where is the interrupt ?? Hidden in that mess?

There are two conditions where Dat1 is used to signal an SDIO interrupt to the host:

• when there is no data activity, Dat1 is asserted
• when there is active data transfer, Dat1 is asserted during an Interrupt Period.

The details are in the actual SDIO spec. Unfortunately, it is not covered in the Simplified SDIO Spec. If you have access to the SDIO spec, the details on how Dat1 is used as a SDIO interrupt will be covered.

Here is what the Simplified SDIO spec says:

[SohKamYung-Espressif]

So I dusted down the analyzer and booted up the rather nice new Saleae Logic 2.

As you using an extension to decode the SDIO data? If yes, which one are you using?

There is a SDMMC from SPI extension which I use that can decode the SDMMC data, including the response, more or less correctly. I have modified the original extension to understand SDIO CMD52 and CMD53. You can get it from https://github.com/SohKamYung-Espressif/saleae_sdmmc_from_spi

[claydonkey]

@SohKamYung-Espressif

As you using an extension to decode the SDIO data? If yes, which one are you using? I'm using this: https://github.com/airbus-seclab/sdmmc-analyzer.git I was using Logic 1.2 b4 and I was using the same analyser: But golly gosh logic 2 is a far superior product:

[claydonkey]

There are two conditions where Dat1 is used to signal an SDIO interrupt to the host:

• when there is no data activity, Dat1 is asserted
• when there is active data transfer, Dat1 is asserted during an Interrupt Period.

I wonder if there is a way to dispense of reading the interrupt when the host is running full pelt. I got better results when the interrupt was ignored for high bandwidth conditions but the unmerited calls to sdio_get_intr increases demands when in low bandwidth or idling. I want to ultimately use the host to run my product software which is already quite demanding.

I previously created a low overhead stm32 spi host for WIFININA - using interrupt routines. I got around 4Mbps for UDP server.
This left the stm32 free to contain/run my apps source effectively. 8Mbps is the goal, so you can my dilemma here.

[claydonkey]

Blimey @SohKamYung-Espressif you are a smart cookie 🥇

[mantriyogesh]

Isense you have two issues: (1) CPU (major issue due to non availability of reliable interruot source) (2) Memory

Addressing memory issue here. @SohKamYung-Espressif will reply for CPU in short.

Mempool might be allocating higher block sizes than it needs. This came from spi background, where the block size is fixed to 1600. Sdio case it still depends upon use, it could be exact size / aligned with DMA/ Aligned with block size that is 512. Depending upon how much are sending. (Both, start address and allocation size) \ You can also comment mempool by undefining CONFIG_ESP_CACHE_MALLOC in sdkconfig.h or your config, where it should be. But despite commenting, if you see this issue, we would have to optimize above paragraph.

This is host side mempool (or cache of mem pointers I should say). Regarding this, For now you can actually also comment. But anyway, allocation size needs to be changed to actual size to read or write. What I mean is, https://github.com/espressif/esp-hosted/blob/7dc00559a1d7991f06e07cc3ff1ede1a9a427ff3/host/drivers/transport/sdio/sdio_drv.c#L121 -> second argument should be real len_to_read (or similarly len_to_write), instead of MAX_SDIO_BUFFER_SIZE.

So commenting of mempool should be also additionally using the real sizes to allocate. As said earlier, this currently resembles SPI, where we have always 1600 bytes. But SDIO case can be addressed differently for optimal memory.

Other midway optimization I can think of is, cache pool of aligned sizes, like say 64 bytes, 128 bytes, ... 512*3 bytes. But this needs to be implemented carefully, to avoid any issues.

[SohKamYung-Espressif]

@claydonkey

I wonder if there is a way to dispense of reading the interrupt when the host is running full pelt.

There are two alternatives that I can think of at the moment:

1. Run the SDIO in 1-bit mode. In this mode, only Dat0 is used for data. Dat1 is then used only for interrupt signalling, which can be handled by a GPIO input interrupt handler.
2. Implement an OOB (out of band) interrupt, using a dedicated GPIO from the slave to the host. The slave asserts the interrupt when it has data to send to the host, and deasserts the interrupt when all data has been read by the host.

Try 1. first and see if the throughput in 1-bit mode can meet your requirements.

[mantriyogesh]

The point (2) is just similar to the DataReady pin in SPI. You can use similar (not the same!) implementation from esp to host interrupt. Assert interrupt as soon as you have tx pending at slave. once the tx pending data is written, the interrupt line is de-asserted.

At host, this will be altogether simple GPIO interrupt. and wait_intr will actually use this GPIO interrupt over (binary) semaphore.

[claydonkey]

@mantriyogesh I think we've covered it.

The OOB hardware solution seems to be the easiest to implement. @SohKamYung-Espressif FYI Basically I have 2 versions of my product. Both use a variant of the STM32H7*** and are clocked at the same speed.

a. STM32H7B0 low pin, low memory - budget version - I'll probably use the esp32 WIFININA for this as I can still use USB. b. STM32H7B3I high pin, external OCTOSPI memory. Sacrifices the USB HS interface for external OCTOSPI - This will be esp-hosted

I have spent months looking for a good/affordable WIFI chip/module. TBH Espressif has the only acceptable solution.

[mantriyogesh]

1. I think if you just push little to get reliable interrupt on SDIO, this all effort will be fruitful. We have Nucleo-H743ZI2 with us. If you think it is good idea, we can try (of course, along with other work!).

2. In case (b), I assume that you wish to use sdio. As STM32 also provides multiple SPI peripherals, you can also use SPI interface with ESP32. SPI interface is easier and gets reliable interrupt as we have tested in production as well. Problem with STM32 SPI is NSS (CS), we already take care of NSS using normal GPIO. I suppose you have 6 SPI peripherals on the STM32 board you use.